adding relation 'instrument in', vs adjusting 'accomplice in'?

[jonathanvajda]

I am looking for a relation for instrumental objects of a process (roughly corresponds to the dative case of means), that is more specific than mere participates_in. If I make a SPARQL query for participants that are not agent_in that process, it'll give more participants than I'd like to return in the query. I'd need to also exclude some inputs ('is input of') but that is not always desirable, exclude some affected participants ('is affected by'), also not always desirable. It seems like the query would have to be ad hoc or hard to provide general guidance on, depending on the process I have in view. This is odd because the relation I have in mind is reusable across a wide variety of processes, and seems like general guidance would be feasible.

Examples:

• Truck instrument_in Act of Vehicle Use
• Infrared Camera instrument_in Act of Sensing
• Weapon instrument_in Act of Weapon Use
• Radio Transponder instrument_in Act of Communication

The domain and range of CCO:'accomplice in' seem like a good pre-existing relation for the semantics of the relation to be 'instrument in'. The domain of 'accomplice in' is BFO:'material entity'; the range is BFO:process, however:

• 'accomplice in' seems to bring not only connotations of instrumentality but also being an Agent (Person or Organization). The definition given confirms this, since it says "an agent a1 is accomplice_in some Processual Entity P1...". This suggests that the domain restriction should be 'agent'. This matches standard dictionaries on the use of the term 'accomplice', for whatever that's worth.
• 'accomplice in' seems like a subProperty of 'instrument_in' anyway

So, I don't want to use 'accomplice in'.

I am not sure what hard limits to the semantics of instruments, though. Would it be limited to only material entities? I'm not sure. According to Neil Otte [(#104)], it seems that reference systems and scales could be used as an instrument? (not sure he endorses my construal...) If so, the domain would be continuant, but not an immaterial entity? This avoids needing to talking about the reference system bearing a role (which is verboten, given it is a GDC). Maybe this is a worthwhile strategy.

What is everyone's thoughts?

Could we add a relation 'instrument_in' with a domain of BFO:continuant and range of BFO:process? This would also benefit with adding its inverse "has instrument".

Moreover, I'd suggest that if we add 'instrument in' we consider making 'accomplice in' a subProperty of 'instrument in'

[mark-jensen]

We link objects to process via the agent that "uses" it to accomplish the objective of the process. instrument_in seems like a shortcut to me

x instrument_in y = x used_by o agent_in y

The connection to reference systems, and for that matter, measurement units, is a good point. And is reflected by the naming the associated properties, e.g., 'uses reference system'. I have always taken these properties to be a simplification of the more complicated pattern: agent uses some thing which is calibrated according to a reference system to produce a measurement. Others don't agree. This topic is under debate and will certainly come up at some point in the IEEE process.

reference system bearing a role (which is verboten, given it is a GDC).

@alanruttenberg can confirm, but it my understanding that GDCs can s-depend. There is also a desire to have GDCs bear roles, eg- some ICE can be used for different purposes.

[jonathanvajda]

Thanks Mark!

First off, let me say I am embarrassed that I didn't see "uses"/"is used by" when I was looking for an appropriate relation. These are sufficient for my purpose.

That said, isn't this a little bit of a surprising pattern? I would think that "uses"/"is used by" would be the shortcut, since sometimes (usually?!) we know the interface or instrument of a process and infer the agent behind it. Cases where we know what was used without knowing who was involved (the make and model of a car, but not the driver), or more about the device than the user anyway (Android device of such-and-such OS, IP address such-and-such, etc.). So, we know some instrument x participates in y, without relating x to some agent z.

I am also imagining models where x is_used_by agent y and y agent_in process z1 and process z2, but we couldn't infer that x participates in process z1 and in process z2. We'd need to assert it in addition. This isn't a problem, it is just something that fits the definition but OWL doesn't give it to us for free. A problem of two-place predicates, I guess.

One virtue of this model is if you have multiple agents and multiple instruments, this definitely seems like a necessary way to differentiate who used what in the process.

[alanruttenberg]

@mark-jensen GDCs can not s-depend. I have been advocating to add an analog to roles for GDCs and will probably create a GDC role class and and associated relation privately until there's support. I suppose we could add it to CCO, but it really ought to be in BFO.

One could consider adding a property chain: used-by o participates-in < participates-in but that gets into trouble because used-by is properly a ternary relation used-by (user, instrument, process). If x used-by y in one process but not in another y participates in, you would still get x participating in both.

A better pattern is to have both the agent and the instrument have roles. x realized in y should infer bearer of x participates in y. Don't recall if that's already an axiom in the OWL but can be added if not. Then assert <role of instrument> realized in <process> and <role of agent> realized in <process>. Then query for what does what based on roles realized in process, rather than by direct relation between agent and instrument. Specialize roles as necessary.

[cameronmore]

I wanted to ask if the team has any plans for adding domain and range restrictions on 'uses' and 'is used by'. The definition asserts that if X is using Y, then X is an agent and Y is a material entity.

But suppose if I'm using an artifact model in the production of a vehicle, it seems like I want to say that I'm using that model. I'm building out a vehicle manufacturing module that asserts that a manufacturer, Honda, uses the Civic Artifact Model (ICE) in an Act of Manufacturing. The link to my module can be found here.

Are there plans to solidify the definition in domain and range restrictions?

[jonathanvajda]

I wanted to ask if the team has any plans for adding domain and range restrictions on 'uses' and 'is used by'. The definition asserts that if X is using Y, then X is an agent and Y is a material entity.

But suppose if I'm using an artifact model in the production of a vehicle, it seems like I want to say that I'm using that model. I'm building out a vehicle manufacturing module that asserts that a manufacturer, Honda, uses the Civic Artifact Model (ICE) in an Act of Manufacturing.

Are there plans to solidify the definition in domain and range restrictions?

I second this. I'm inclined to adjust the definition, but keep the domain and range as is. Case in point, information is used in identifying a person, and used explicitly in document acts. Rather than require the information to bear a role (though this could add to the list of use cases for @alanruttenberg ), it could just have a relation of being used in such-and-such process.

[cameronmore]

I like this solution, it gets around the 'information roles' issue (@johnbeve ) and I would be happy to continue the question of what 'instrumental' means. Are all uses of things instrumental uses?
Another thought: this strategy lets us assert that a computer program, being a material entity, may use a GDC in a process, and now we have a way of talking about the instrumental nature of information and files in digital processes.
Open to more discussion.

[jonathanvajda]

After more consideration, I don't think there is a problem that isn't a general problem with OWL2's two-place relations. I think the only simple way to get around it is to ignore the "uses" relation, and just enumerate a sub-process such as "act of artifact employment" where the agent is the agent_in and the instrument/artifact merely participates_in. This is in effect to reify the triple "Bob uses the car" or "Sam uses the phone" All the best, Jonathan Vajda /dʒɒnɑθɑn vaɪdɑ/

…

On Mon, Nov 6, 2023 at 8:39 PM Cameron More ***@***.***> wrote: I like this solution, it gets around the 'information roles' issue ( @johnbeve <https://github.com/johnbeve> ) and I would be happy to continue the question of what 'instrumental' means. Are all uses of things instrumental uses? Another thought: this strategy lets us assert that a computer program, being a material entity, may use a GDC in a process, and now we have a way of talking about the instrumental nature of information and files in digital processes. Open to more discussion. — Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIW242DLCKL4GTMCBEVALRLYDGGLJAVCNFSM6AAAAAA3UNY25WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGEZTGNJVGM> . You are receiving this because you modified the open/close state.Message ID: ***@***.*** com>