relations for GDCs

[GoogleCodeExporter]

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 reported on code.google.com by bjoern.p...@gmail.com on 16 Dec 2009 at 3:24

[GoogleCodeExporter]

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.

Original comment by batchelorc@rsc.org on 17 Dec 2009 at 3:33

[GoogleCodeExporter]

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. 

Original comment by bjoern.p...@gmail.com on 17 Dec 2009 at 3:58

[GoogleCodeExporter]

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

Original comment by cmung...@gmail.com on 17 Dec 2009 at 4:33

[GoogleCodeExporter]

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)

Original comment by bjoern.p...@gmail.com on 17 Dec 2009 at 4:58

[GoogleCodeExporter]

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.

Original comment by cmung...@gmail.com on 17 Dec 2009 at 7:11

[GoogleCodeExporter]

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/bc5082f
6174520aa#
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. 

Original comment by bjoern.p...@gmail.com on 17 Dec 2009 at 7:50

[GoogleCodeExporter]

Needs review in light of BFO2 Reference

Original comment by alanruttenberg@gmail.com on 7 May 2012 at 4:53

• Added labels: Review-Old-Issue, Type-BFO2-Reference
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by alanruttenberg@gmail.com on 8 May 2012 at 4:15

[GoogleCodeExporter]

Original comment by alanruttenberg@gmail.com on 8 May 2012 at 4:37

• Changed state: Review-old-issue