[Obi-protocol-application-branch] reorganization below 'information object'
Bjoern Peters
All,
(Chris / Alan , can you let me know if this message gets through to the DENRIE branch? I have been burned before).
In todays plan + planned process branch call, we came across problems with the plan terms that are most likely best addressed across our two branches. We have put a proposal into svn (without touching the DENRIE branch file so far). We thought it is easier to put in something concrete, and revert if it is hated.
To walk through the issues:
- Initial problem: Realizable information entities should be realized (in the BFO sense) as a process. This makes some of the classes we have under this misplaced, such as 'data format'.
- We would like to introduce a parent class under information_entity called 'specification', which has 'realizable information entities',
Requests to DENRIE:
- move programming language out of 'plan'
- move 'objective' into our branch (to be placed under 'specification')
Action items for our branch:
- We need to clarify the class instruction triggers / rules, and how they overlap with 'constraints'
- We need to clarify the class algorithm
- We need to clarify the distinctions and relations between investigation_design, study_design and protocol
Remaining issues: The hierarchy under non-realizable information entity would need to be changed as well, as specification and 'non-realizable information entity do not make good siblings. Right now I am uncertain what the difference between 'information entity', 'non-realizable information entity' and 'information content entity' is. I have some not well thought through proposals on this, and stop now to keep this email from getting any longer.
- Bjoern
Bjoern
Peters
Research Scientist
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA
92037, USA
Tel.: 858/752-6914
Fax: 858/752-6987
Chris Stoeckert
- move 'objective' into our branch (to be placed under 'specification')
Chris Stoeckert
Requests to DENRIE:- move programming language out of 'plan'
Matthew Pocock
> Dear Bjoern,
>
> > Requests to DENRIE:
> > - move programming language out of 'plan'
>
> This was discussed today at the DENRIE call. We agree (at least the 4
> of us on the call) that programming language is not a plan and
> recommend moving it up to under specification. We view a particular
> software program as a plan or set of instructions but the language in
> which the program is written to be a specification and a sibling to
> data format specification.
>
> Cheers,
> Chris
Hi,
While I agree that programming languages are not plans, I'd also say that
programs themselves are not plans, although they can be interpreted that way.
Anyway, could you clarify for me what classes, instances and relations we use
for capturing this information concretely? Let's take a specific case:
Programming language, Java, Application, JEdit, the instance of JEdit that is
executing on my computer now.
Thanks,
Matthew
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Obi-protocol-application-branch mailing list
Obi-protocol-ap...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-protocol-application-branch
Alan Ruttenberg
I don't think we have a good definition of a programming language yet.
The JVM would be a software interpreter encoded as a binary executable
The Application JEDIT would be an algorithm encoded as a binary
executable.
concretizations of the JVM and JEDIT inhere in some part of your
computer hardware.
The "instance of JEDIT" that is executing on your computer now would
be a process.
The Java that constitutes the source code of JEDIT is a realizable
information entity (though Barry correctly notes that concretizations
are realizable, not the IE itself). The JEDIT binary executable is an
encoding of that source code.
JEDIT running is the realization of the concretization of the
encoding of the JEDIT source code.
Undoubtedly I've made a mistake somewhere in the above, but that
should get the conversation going.
What do you think is missing/wrong.
-Alan
Bjoern Peters
Hi Chris,
Sorry for my delay in responding. This one is for last weeks email. It looks my original email was broken off one important sentence in the middle (sorry):
We didn't intend for 'objective' to become realizable. 'Specification', where we proposed to move it in, is not supposed to be realizable (as a process), but have 'realizable specifications' as a subclass.
I totally agree with your email from yesterday on programming languages being a sibling of 'data format specifications'.
- Bjoern
Bjoern Peters
information branch questions relevant to the branches.
I was warned not to enter this discussion if I want to have a life :)
Clearly this is not a core OBI problem, and while not out of scope, I don't
think we should spent significant resources on such questions on these
branch lists. It is darned interesting though.
Still, I would urge to take this offline with interested parties only; don't
know if that includes all of the DENRIE branch. Anybody interested should
reply to one of the emails.
That said, my take:
- I agree with what Alan wrote
- As Chris wrote, a programming language, in terms of the rules how to write
valid code, should be a 'specification', sibling of 'data format
specifications'
- programming code (e.g. a source code file) is an information entity
conforming to the programming language specifications
- A programming language compiler or interpreter takes an information entity
written according to the programming language specifications, and translates
it (in multiple, convoluted steps not worth modeling in my opinion), into an
'application' = entity realizable by a user. The running application is a
process.
Chris Stoeckert
Bjoern Peters
This is the 'remaining issue' that was at the bottom of the original email.
We agree that the siblings like this are not okay. We did not want to touch
'non-realizable information entity', because that was solely DENRIE
territory. Our question to you was: What is the difference between
'information entity', 'non-realizable information entity' and 'information
content entity'?
My not yet well thought out gut feeling says, there is a key difference
between 'specification' information entities, that you can use to classify
all kinds of other entities into conforming and non-conforming, and
'descriptions' / 'representations' / 'content entities', that convey
information about specific instances.
- Bjoern
________________________________________
From: Chris Stoeckert [mailto:stoe...@pcbi.upenn.edu]
Sent: Wednesday, April 02, 2008 1:42 PM
To: Bjoern Peters
Cc: obi-protocol-ap...@lists.sourceforge.net;
obi-denr...@lists.sourceforge.net
Subject: Re: reorganization below 'information object'
Hi Bjoern,
What I'm pondering is whether the current hierarchy (illustrated below)
Chris
________________________________________
From: Chris Stoeckert [mailto:stoe...@pcbi.upenn.edu]
Sent: Monday, March 24, 2008 2:00 PM
To: Bjoern Peters
Cc: obi-protocol-ap...@lists.sourceforge.net; obi-denrie-branch
-------------------------------------------------------------------------
Chris Stoeckert
We, the DENRIE branch, will work on this, review the definitions, and
get back to you.
Cheers,
Chris
Bjoern Peters
Matthew Pocock
On Wednesday 02 April 2008, Bjoern Peters wrote:
> I changed subject to separate this from the general re-organization under
> information branch questions relevant to the branches.
:)
>
> I was warned not to enter this discussion if I want to have a life :)
> Clearly this is not a core OBI problem, and while not out of scope, I don't
> think we should spent significant resources on such questions on these
> branch lists. It is darned interesting though.
Yeah.
> That said, my take:
> - I agree with what Alan wrote
> - As Chris wrote, a programming language, in terms of the rules how to
> write valid code, should be a 'specification', sibling of 'data format
> specifications'
> - programming code (e.g. a source code file) is an information entity
> conforming to the programming language specifications
>
> - A programming language compiler or interpreter takes an information
> entity written according to the programming language specifications, and
> translates it (in multiple, convoluted steps not worth modeling in my
> opinion), into an 'application' = entity realizable by a user. The running
> application is a process.
OK, I'm agreeing with both Bjoern and Alan up untill the bit about the
application. The compiler turns one information entitiy into another. The new
one, in my view, has the same ontological status as the original. What is
potentially different about it is that people have the intent to execute the
result. They call it an 'application' becuase of their intent not because of
what it inherently is.
For example, I could take Java source code and run it in an interpreter. I
could compile it into bytecode and run it in a JVM. I could compile the
byte-code into machine-code and run that directly on the chip. I could
equally compile some Java code to byte-code without any intention ever of
running it, simply to prove that a certain arangement of statements have
certain effects uppon the compiler.
So, application seems to be analogus to a 'function' to me. Just as knives are
knives becuase we have a social contract that pointy, flat things that are
used for cutting have the functional designation 'knife', comuter code that
when executed performs a task for the user has the functional
designation 'application'.
The thing I still think we are missing is a recognition that evaluation of
code is a process in its own right. Programs don't just run. There is a
running process that takes the application as input. This is analogs to lab
work where an experimental protocol doesn't just happen, there is an agent
who 'runs it' and we call them lab techs, students or RAs. Realization of
these things (if realization is the right thing here) is through a process.
Matthew
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Philippe
I tend to agree with Bjoern regarding the scope but since the discussion
is on, I have noticed the following:
'software interpreter' is currently a child of algorithm (itself a child
of specification)
2 comments:
i. I have added a definition to algorithm based on a discussion that
took place some months ago. I would tend to agree with Christian Cocos,
that algorithm is more a kind of plan than a specifications.
(the definition I have added actually reflect the fact that I consider
algorithm as a plan). I realize that we may go over a long thread on
this issue.
ii. I thought a software interpreter was a software itself ? (a software
interpreter may implement a software interpreter specification though.)
Cheers
Philippe
Bjoern Peters
-----Original Message-----
From: obi-protocol-applic...@lists.sourceforge.net
[mailto:obi-protocol-applic...@lists.sourceforge.net] On
In 15 minutes
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.5/1358 - Release Date: 4/3/2008
6:36 PM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.11/1368 - Release Date: 4/9/2008
4:20 PM
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Bjoern Peters
to distinguish an 'application' from 'programming code', but there is a need
to talk about executing code.
Is it accurate that the three things we care about are:
* the programming language = the specification how to encode instruction
for a computer in a language (to be able to say: this is C source code)
* computer software = programming code = the realizable information entity
containing instructions that can be executed by a computer and modified by a
programmer
* running software = executing programming code = the process of a computer
running an application (compiled, interpreted, virtual machines, microcode:
who cares).
- Bjoern
Hi,
:)
Yeah.
what it inherently is.
Matthew
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Alan Ruttenberg
I think that in some cases programming texts and applications might
applications coincide. But some differences are: Programming texts
includes information that is not meant as instruction for the
computer but aimed instead at a person - the comments, and the visual
layout. Those comments are about the expression in the programming
text, not about their translations. Moreover programming texts may be
incomplete or have syntax errors. A given programming text can not
necessarily run as an application - it may need the inclusion of
other texts to make it so.
I think the situation is similar to the case of the various
information entities in a document.
In my ongoing discussion of information with Barry and others, all
seem to agree with the following:
>> One thing that there seemed to be consensus about was what I call the
>> multiplexing of information entities. So consider a fragment of the
>> constitution layed out on a printed page. One information content
>> entity is the wording. Another might be the layout (vis. the layouts
>> you can choose in word with lorum ipsum.... blank content). Someone
>> might create the line breaks so that the first letter of each line
>> spells out another message. There was general consensus that this was
>> 3 things.
Perhaps we have that programming texts are narrative objects, a
portion of which can be interpreted as computer software. Can't get
the wording right atm, as I'm in a rush, but if you agree we can work
together on it.
-Alan
Chris Stoeckert
Just an update on this topic. At the DENRIE call on Monday (the 14th)
we discussed the top level information entity hierarchy. We still need
further discussion on clarifying 'information entity', 'non-realizable
information entity' and 'information content entity.' However, we
wanted to relay that the DENRIE branch (at least the 5 of us on the
call) agreed that realizable information entity should be a child of
information entity and a sibling of non-realizable information entity
(i.e., it's position with respect to specification should be flipped).
We note that data format specification, instruction trigger, and
algorithm are currently siblings of realizable information entity but
are in fact realizable. If you (protocol application) agree, then we
can assign someone to make the change in OBI.
We will also keep you abreast of our discussion on the definitions of
the 'information entity', 'non-realizable information entity' and
'information content entity.'
Cheers,
Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Bjoern Peters
I was actually trying to get rid of defining what an 'application' is, and
rather focus on the distinction that 'programming text' = can be 1) edited
or 2) executed. I didn't make that explicit enough, so I have now added the
'modifiying' process. I also integrate specifically your request for
'comments in code'.
Is it accurate that the four upper level classes we care about when
referring to computers/programming in OBI are:
* programming language is the specification how to encode instruction for a
computer in a language. (Example: the C language)
* computer software (= programming text) is the realizable information
entity containing instructions that can be executed by a computer and
modified by a programmer. It can include information content that is not
executed by the computer, such as comments. (Example: Microsoft outlook
2003. A text file containing "print 'hello world' #python rules")
* executing computer software (= executing programming text) is the process
of a computer running an application. (Example: the instance of Microsoft
outlook running on my machine in which I type this. The usual generically
dependent --> concretized ... steps apply)
* modifying computer software (= modifying programming text) is the planned
process in which a computer programmer changes computer software with the
objective to modify the process realized in its execution or to modify the
information visible to programmers.
Bjoern Peters
The position of specification was intentional as the parent, and I want to
make the argument why I don't believe all specifications are realizable.
The html 3.0 data format specification defines what digital entities are
valid html 3.0. With the html 4.0 specifications coming out, some digital
entities that are valid html 3.0 are also valid html 4.0. What is the
relationship between the digital entity and the specification? At least this
example tells me that the document is not an output of a 'realization of'
the specification.
There are more such specifications non-processes, such as classification
schemes that assign tumors to a certain class based on tumor diameter, or a
regulation how large a cage has to be to house mice.
I may simply miss how you wanted the realizations of specifications to be,
but I hope I have communicated why I believe they are distinct from plans. I
will happily change my mind. If you feel it would help, I could join one of
your calls.
- Bjoern
Alan Ruttenberg
software isn't = programming text. Transformations of the programming
text by compilation can also be executed, but are typically not
modified by a programmer, and when modified aren't modified in the
same way as the programming text. I think the programming text has
elements of being a narrative object. Transformations of it, such as
stripping comments, translation to byte code or machine language,
packagings in libraries, dlls, are different entities that may need
to be referred to by OBI, because the specific packagings of them
have versions and OS specific variants that might be important to
note if we want to be able to convey enough information to replicate
some analysis. I think we are closer to understanding applications
(if we care to) if we note that they are derived from collections of
transformations of programming texts possibly authored by many
different programmers, and more.
-Alan
Chris Stoeckert
Will take up the discussion of data format specifications with the
rest of the DENRIE branch but there is still an issue with the
hierarchy even if you are right.
Current hierarchy under information entity:
specification ( realizable and nonrealizable)
realizable infromation entity
data format specification (may not be realizable)
nonrealizable information entity
information content entity
digital entity
An alternative:
realizable infromation entity
realizable specifications
nonrealizable information entity
data format specification (if not realizable)
information content entity
digital entity
Another alternative eliminating non-realizable information entity:
specification ( realizable and nonrealizable)
realizable infromation entity
data format specification (may not be realizable)
information content entity
digital entity
Cheers,
Chris
Bjoern Peters
software/application will always lead to problems nailing down what the
involved transformations are, as Mat pointed out earlier (virtual machines,
compiled vs. interpreted etc, FPGAs natively executing high level
languages).
I believe that any 'computer software' = 'programming text', because it can
always be edited by a programmer or executed by a computer. The different
transformations just make one or the other MUCH easier. Example: using a
disassembler to modify Microsoft Word.
In this view, dll's or compiled C code for different operating systems are
different subclasses of computer software. Compilers and interpreters
themselves are computer software.
I agree that it is necessary to point out that software is typically a
collection of pieces (each of them software) that interact during execution.
Bjoern Peters
I agree that the hierarchy is messed up, and the clarifying what
'specifications' are will not fix it one way or the other. I like your
alternative 2. Below I am populating it with how I would place some
additional terms:
specification
realizable specification
plan
protocol
investigation design
computer software
non-realizable specification
data format specification
programming language
regulation / law
objective
information content entity
digital entity
As a general apology for this and the following: The 'information' subjects
fascinate me, and seem so much more interesting than what I should work on
right now (grant writing). Please don't take my emails as an attempt to
interfere with your branch work. Feel free to vote me down on everything, as
I may simply not be aware of design decisions you made earlier. Minimally I
hope my suggestions are useful to point out where it is hard for an outsider
to understand the current structure.
- The relationship between specifications and other entities are entity
'conforms with' specification; what relations are there for
non-specifications? E.g. shouldn't there be something like a 'description'
relationship so that entity 'is described by' information? Examples:
'weight of mouse is described by 150 g'. 'investigation X is described by
journal publication Y'.
- Are digital entities just one specific encoding of information entity? If
it is a class here, shouldn't other encodings be listed as well (symbolic,
mental, visual, audio, tactile)? If digital entity is more than an encoding,
how do we deal with e.g. digital vs. non-digital images?
Alan Ruttenberg
the same bearer can bear multiple information entities. Here's how I
summarized this to Barry recently
> One thing that there seemed to be consensus about was what I call
> the multiplexing of information entities. So consider a fragment of
> the constitution layed out on a printed page. One information
> content entity is the wording. Another might be the layout (vis.
> the layouts you can choose in word with lorum ipsum.... blank
> content). Someone might create the line breaks so that the first
> letter of each line spells out another message. There was general
> consensus that this was 3 things.
To solve the puzzle that some programming texts seem
indistinguishable from software, consider that there are two
(related) information_entities
The first is the one that is authored by a programmer. It can contain
comments and other elements (e.g. structural indentation) that do not
contribute to the execution. The other is (analogous to the wording
example above) the portion that is meaningful as a portion of an
application (runnable software).
The entites are then something like:
Programming texts: narrative objects that attempt to conform to a
programming language specification.
Software entity: series of encoded instructions that can be directly
executed by a CPU, or transformed in to a form that can be. For
programming texts that are syntactically correct and which are in a
language that can be executed by an interpreter this would correspond
to the tokenized version of the text stripped of comments.
Application: An aggregation of software entities adequate to, when
added to the set of already present software on a computer, be
executed and realize new functionality.
Operating system: An application that provide a background set of
functionalities which other applications can take advantage of, but
which itself does not depend on software functionality other than a
BIOS or similar low level software to control and access hardware.
The language of these definitions is still not nice - too jargony -
but my intention isn't to get the defs perfect yet, but to see
whether this breakdown seems like it could work.
-Alan
Bjoern Peters
I think I understand what you are suggesting, but I do not understand why.
Can you explain the benefit of having distinctions between programming text,
software entity and application? I am not sure:
* Is programming text in an interpreted language that is syntactically
correct and without comments a software entity or a narrative object?
* Is an aggregation of software entities a software entity?
* Is a single software entity that can be executed an application?
* what examples of software entity that are not applications do we want to
model?
* what is byte code I modify with a hex editor?
You probably have similar and worse problems with my proposal that I don't
see. If so, please let me know .
- B
Alan Ruttenberg
On Apr 23, 2008, at 12:49 AM, Bjoern Peters wrote:
> Alan,
>
> understand why.
> Can you explain the benefit of having distinctions between
> programming text,
> software entity and application? I am not sure:
>
> * Is programming text in an interpreted language that is syntactically
> correct and without comments a software entity or a narrative object?
answer)
> * Is an aggregation of software entities a software entity?
instructions created for a powerpc and those that created for an intel
processor. Example yes: An application ;-) Note that with the correct
packaging (e.g. "fat binaries") a software entity that has a part
compiled for powerpc and a part compiled for intel, can still be
executed. This is because it has some extra instructions that indicate
to the operating system that these parts are both present, and where.
> * Is a single software entity that can be executed an application?
software entity or aggregation of software entities".
> * what examples of software entity that are not applications do we
> want to
> model?
> * what is byte code I modify with a hex editor?
saved as byte codes and not text then the programming text evaporates
and you are left with a software entity. Think of the hex editor is a
kind of compiler or interpreter.
> You probably have similar and worse problems with my proposal that I
> don't
> see. If so, please let me know .
a person, versus transformations of them. Portions of the programming
text that were not interpretable as instructions were not accounted
for, nor were programming texts with syntax errors. You agreed that
the notion of aggregate was needed, but didn't supply a modified
definition that took it in to account. There was no distinction
between operating system and application, or between application and
library.
Best,
Alan
Bjoern Peters
Breaking down the problems you mention in my approach with *:
* There wasn't an appropriate distinction between artifacts authored by
a person, versus transformations of them.
In my view, software as authored by persons and transformed by computers is
software. I don't see the benefit in enumerating the transformations
possible for OBI purposes, specifically as each of those can again be
modified by a person. Your description of the hex editor agrees with that,
as you say that programming text doesn't have to be authored by persons, but
can be created by machines from an application.
* text that were not interpretable as instructions were not accounted
For
A comment or insignificant whitespace in a software entity is a part that is
lost in a transformation processes prior to execution. So are instructions
eliminated by a compiler optimization procedure, like functions that are
never instantiated or don't do anything. E.g. how is this instruction set
different from the comment:
def calc_meaning_of_life():
pass # need to remember to improve this function later
* nor were programming texts with syntax errors.
I thought we do not try to account for broken legs, investigations in which
the investigators run off to Hawaii and software that has syntax errors in
the definitions of legs, investigations or software?
* You agreed that the notion of aggregate was needed, but didn't supply a
modified definition that took it in to account. There was no distinction
between operating system and application, or between application and
library.
will tackle tomorrow, need sleep now.
After going through your responses, I wonder what makes a jar file not be an
application according to your definition?
> when
> added to the set of already present software on a computer, [it can] be
> executed and realize new functionality.
With your answers, I only see 'broken software' that cannot be executed not
being an application. As stated above, I thought we do not try to include
broken things in these considerations.
I do think this discussion is helping clarify things for me at least.
Alan Ruttenberg
> Alan,
>
>
> * There wasn't an appropriate distinction between artifacts authored
> by
> a person, versus transformations of them.
>
> In my view, software as authored by persons and transformed by
> computers is
> software. I don't see the benefit in enumerating the transformations
> possible for OBI purposes, specifically as each of those can again be
> modified by a person. Your description of the hex editor agrees with
> that,
> as you say that programming text doesn't have to be authored by
> persons, but
> can be created by machines from an application.
I didn't suggest that we had to enumerate the transformation. I'm more
concerned with naming the entities.
Good point about the hex editor creating a program text.
> * text that were not interpretable as instructions were not accounted
> For
>
> A comment or insignificant whitespace in a software entity is a part
> that is
> lost in a transformation processes prior to execution. So are
> instructions
> eliminated by a compiler optimization procedure, like functions that
> are
> never instantiated or don't do anything. E.g. how is this
> instruction set
> different from the comment:
>
> def calc_meaning_of_life():
> pass # need to remember to improve this function later
This strengthens the distinction. The software is the encoding of
instructions. The programming text is more.
> * nor were programming texts with syntax errors.
>
> I thought we do not try to account for broken legs, investigations
> in which
> the investigators run off to Hawaii and software that has syntax
> errors in
> the definitions of legs, investigations or software?
We're in a different realm where we need to describe what people
create. Are we not going to represent, in OBI, study reports that have
mistakes in them? To be clear, we won't examine, when labeling
something a study report, whether it is correct or not, or whether it
has the right sections.
> * You agreed that the notion of aggregate was needed, but didn't
> supply a
> modified definition that took it in to account. There was no
> distinction
> between operating system and application, or between application and
> library.
>
> will tackle tomorrow, need sleep now.
OK. Or you could use my version ;-)
>
> After going through your responses, I wonder what makes a jar file
> not be an
> application according to your definition?
Many can't be executed independently, because, for instance, they
don't have a main().
>> when added to the set of already present software on a computer,
>> [it can] be
>> executed and realize new functionality.
>
> With your answers, I only see 'broken software' that cannot be
> executed not
> being an application. As stated above, I thought we do not try to
> include
> broken things in these considerations.
>
> I do think this discussion is helping clarify things for me at least.
Likewise! Thanks for the jousting!
-Alan
Clancy, Kevin
Here is a modified PlanAndPlannedProcess.owl file. You will find that I
worked on a number of areas under material transformation:
Amplification
_cloning placeholder
Material separation->chromatography
I think Bjoern would like to go over at least some of these proposed
changes/additions in tomorrow's call.
kevin
-----Original Message-----
From: obi-protocol-applic...@lists.sourceforge.net
[mailto:obi-protocol-applic...@lists.sourceforge.net]
Bjoern Peters
I owe you a response on this for the past month. I want to devote this
week to bringing outstanding OBI issues I am potentially holding up to a
close. For this one, I don't believe we are far apart. The main
difference I believe is your wish for a finer breakdown of terms that I
would consider higher level. This includes distinguishing comments and
code in programming text or distinguishing libraries, applications and
operating systems. While I still have prefer my approach, I want to try
something new, and trust your judgment.
Reading back over the entire email exchange, trying to agree with
everything you write, I understand you are saying the following.
Your definitions:
* Programming texts: narrative objects that attempt to conform to a
programming language specification.
* Software entity: series of encoded instructions that can be directly
executed by a CPU, or transformed in to a form that can be. For
programming texts that are syntactically correct and which are in a
language that can be executed by an interpreter this would correspond
to the tokenized version of the text stripped of comments.
* Application: An aggregation of software entities adequate to, when
added to the set of already present software on a computer, be
executed and realize new functionality.
* Operating system: An application that provide a background set of
functionalities which other applications can take advantage of, but
which itself does not depend on software functionality other than a
BIOS or similar low level software to control and access hardware.
Not your definitions, but I take that you would agree with the following from our follow up discussions:
* a programming language is the specification how to write programming text that can be transformed into software for a given language.
(Example: the C language)
* executing software is the process by which a computer/CPU follows instructions encoded in software
* an application is a software
I believe something addressing the following is necessary, but am not sure what your definitions would be
* transforming programming texts into software (examples: compiling, interpreting, hex-editors closing)
* programming = modifying programming texts (never software, right?)
Is this what you had in mind? What else is missing?
My original reason to get involved with this discussion were my problems
with how these terms are currently placed, and still are. Currently
'programming language' is a realizable 'plan' while 'binary executable'
is a 'non-realizable information entity'. This is wrong any way you look
at it. I care because I was supposed to get the distinctions between
realizable and non-realizable information entities straight,
specifically 'objective', 'specification', and 'plan'. Clearing this up
is important to get the distinction straight between the plan+planned
process branch versus the denrie branch
Would you agree with the following:
* the process of executing 'software' is a kind of process of realizing
an 'information entitiy'.
* non of the other named entities is 'realizable' (counting operating
system and applications as software).
If you agree, I would place software as a sibling of 'plan' under
'realizable information entity'.
- Bjoern
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Alan Ruttenberg
Alan,