relations for GDCs

[zhengj2007]

From bjoern.p...@gmail.com on December 15, 2009 22:24:12

As discussed in the IAO call and with input from Barry:

• The domain of 'inheres in' should be limited to specifically dependent continuants.
• The textual definition of 'is_concretization_of' should reflect that.

Original issue: http://code.google.com/p/bfo/issues/detail?id=10

[zhengj2007]

From batchelorc@rsc.org on December 17, 2009 07:33:30

depends_on is true but seems a little weak for the relation, say, between a gene and its DNA molecule. There are other existential dependences, for example between a gene and the transcription process, and even more trivial ones.

Is there to be an inheres_in analogue for GDCs?

Colin.

[zhengj2007]

From bjoern.p...@gmail.com on December 17, 2009 07:58:34

It should be: every GDC is_concretized_as one or more SDC, and every SDC inheres_in exactly one independent continuant. This implies that we can define a shortcut relation saying that every GDC 'generically inheres in' one or more independent continuant (through its concretizations).

I would favor not introducing those shortcut relations now though, as writing it out forces to think about the difference between GDC and SDC which I don't think everyone is fully aware of right now.

[zhengj2007]

From cmung...@gmail.com on December 17, 2009 08:33:30

This seems a bit perverse. You'll force people to write

geneX is_concretized_as some (SDC that inheres_in some chrY)

in order to educate them via torture?

If for one will use the shortcut relation as I don't even have the slightest inkling what that intervening SDC is or how I would detect it etc

[zhengj2007]

From bjoern.p...@gmail.com on December 17, 2009 08:58:15

If you need the shortcut relation, fine, but are you not worried by your own statement that you don't know what the intervening SDC is? In IAO at least, this proved problematic, as different developers had different understandings of what this middle layer that is being glossed over is.

In IAO, the distinctions are important. For example an instance of a 'measurement datum' is_concretized_as an 'ink pattern' that inheres in a 'page in lab notebook'

I thought in your gene example, the pattern would be geneX is_concretized_as some (primary_structure that inheres in some DNA molecule)

[zhengj2007]

From cmung...@gmail.com on December 17, 2009 11:11:10

I think the ink pattern is a GDC. If I photocopy your lab notebook then we have the same ink pattern.

In one of the earlier alpha versions of RO2 we had

• inheres_in * specifically_inheres_in * generically_inheres_in

See my ppt from the RO meeting.

This seems simple and mirrors BFO (I thought the definition of dependent continuant was something can inhere_in (according to Pierre, the current bfo def is incoherent))

Axioms can just use inheres_in, if I say q inheres_in c, q instance of SDC, then we know q specifically_inheres_in c from supporting axioms.

[zhengj2007]

From bjoern.p...@gmail.com on December 17, 2009 11:50:46

I am off to the airport in a few minutes, so won't be able to respond further after this.

Briefly: This is the result of a discussion on the IAO list, which is unfortunately messy. The full thread is here: http://groups.google.com/group/information-ontology/browse_thread/thread/bc5082f6174520aa# and I am copying Barry's feedback on the initial start in below. There are still open issues (specifically the bit about dealing with plans), but there was general agreement on the bits about concretization and inheres_in which I submitted here.

The 'ink pattern' (we switched to: 'optical surface pattern', but I thought 'ink pattern was more intuitive') is defined as a quality of the paper. When I write something on a piece of paper, give it to you to read and you burn it afterwards, the ink/optical surface pattern is gone, but the information content entity still exists (concretized in your brain somehow).

Again: I am okay with having the three inheres in relations, but if that glosses over fundamental disagreements of what concretizations are and how to work with GDCs, than I think that hurts us significantly. I think we just need the specifically inheres in relation and the is_concretization_of relation, and can construct the others based on it.

• Bjoern

Below is the start of the original thread:

----- Forwarded Message ----- From: "Barry Smith" phism...@buffalo.edu To: "Bjoern Peters" bpet...@liai.org Sent: Tuesday, December 8, 2009 12:09:46 PM GMT -08:00 US/Canada Pacific Subject: Re: Fwd: [IAO] ICE and its concretizations

At 03:03 PM 12/8/2009, Bjoern Peters wrote:

Barry: Can you weigh in on the below? That was specifically requested in the call by several during the call, and would be very helpful.

Bjoern. I think what you say below is exactly right. Good to add some axioms to the effect, e.g., that every plan involves a plan specification. This may enable you to simply the definition. BS

----- Forwarded Message ----- From: "Bjoern Peters" bpet...@liai.org To: "information-ontology" information-ontology@googlegroups.com Sent: Tuesday, December 8, 2009 11:06:08 AM GMT -08:00 US/Canada Pacific Subject: [IAO] ICE and its concretizations

Based on some of the email conversations in the past days, and confirmed in todays call, we thought it is necessary to define properly some of the early workshop decisions for IAO which not everybody is aware of, and there seem to be some disagreements about.

It was my understanding that:

1) Every information content entity (ICE) is_concretized_as some (physical) quality. The ICE could be a weight measurement datum. The concretization is the ink pattern written down in a lab notebook, the magnetic pattern in a hard disk, and the 'neural pattern' in someones brain.

2) Each of these qualities 'inheres in' an independent continuant (the paper, magnetic storage, brain)

3) There is no 'inheres in' relation between an ICE and an independent continuant other than to the bearers of the concretized ICE qualities

I noted (as did MC during the call) that we have been treating 'plan' different from the above. We say that a plan is a concretization of a plan specification, and that a plan is a 'realizable entity, not a quality.

I think it is straightforward to make dealing with plans consistent with the above, and that it is desirable. For every plan that is realized, the bearer must be capable of storing information about that plan. It is possible to bear concretizations of plan specifications without the intend or capacity to realize them, like the piece of paper on which a plan specification is written.

Therefore i would propose to modify the definition of plan to be:

plan=def a realizable entity that inheres_in a bearer that has_quality a concretization of a plan specification which the bearer is committed to realize as a planned process.

[zhengj2007]

From alanruttenberg@gmail.com on May 07, 2012 09:53:05

Needs review in light of BFO2 Reference

Labels: -Type-Defect Type-BFO2-Reference Review-Old-Issue

[zhengj2007]

From alanruttenberg@gmail.com on May 07, 2012 21:15:36

Owner: ifo...@gmail.com

[zhengj2007]

From alanruttenberg@gmail.com on May 07, 2012 21:37:13

Status: Review-old-issue