Would like to obsolete: digital quality and children pending "encodings"

[Alan Ruttenberg]

Pending addition of a reasonable way to discuss encodings of
information content entities, I'd like to obsolete some old terms are
just hanging around in IAO.

These are:

Digital Quality
Digital Entity
Binary Digital Entity
Binary Executable
Digital Document
Text Based Digital Document

There is discussion of having a relation is_encoded_as and a number of
classes representing encodings (synonym "data structures") such as
lists, arrays, binary trees, etc.

Distinctions worth making, in this vicinity:

The sense of encodings or data structures are that they determine how
information entities they structure are concretized as specifically
dependent continuant, in such a way as a mechanisms which can
manipulate/access the information specifically dependents can support
a certain set of operations (with given time complexity).
(A nagging feeling here - there are layers of encodings, typically. On
a hard disk one has the logical blocks, for which the operation "next"
is quick, but this can be further encoded as a mapping to several
disks, in which the operation "next" is sometimes quick, and sometimes
possibly not.)

As discussed in the OBI meeting, this is different from structures
used in simulations/models such as network models. The distinction is
that in those cases there is a mapping of such operations directly
into the domain that is being modeled - for instance in a network
model of protein protein interaction, "nodes" represent proteins and
"edges" represent processes, such as binding, and "functional
proximity" is computed by some function on network proximity. The
sense of encoding above has no suggestion that there are analogies to
be made *from the structure, to the entities that the information
content they structure is about*.

Moreover I think some care needs to be taken to make sure that we also
don't confuse them with composite data items. For instance, we may
have a number of measurements that were taken at different times. The
information content entities that are these measurements may or may
not be encoded as a list, or an array, or any of a number of other
data structures.

Your thoughts about both the prospect of deprecating the above terms,
and about ideas about "encodings" are solicited.

Thanks,
Alan

[Melanie Courtot]

Hi,

Some of those terms that have been deprecated have subclasses in OBI,
so it would be helpful to know how to address those before the next
IAO release.

OBI currently has a class "data representational model" (Work in
progress. Currently: alt term data structure, data structure
specification, definition: "Data representational model is an
information content entity of the relationships between data items. A
data representational model is encoded in a data format specification
such as for cytoscape or biopax.") that we created for the purpose of
representing the structure data can have. Maybe we should discuss with
the DENRIE branch on how best to coordinate efforts?

To add to the list of "encodings", how do we deal with character
encoding? (utf-8, latin-1...)

Thanks,
Melanie

[Alan Ruttenberg]

On Wed, Mar 25, 2009 at 2:04 PM, Melanie Courtot <mcou...@gmail.com> wrote:
>
> Hi,
>
> Some of those terms that have been deprecated have subclasses in OBI,
> so it would be helpful to know how to address those before the next
> IAO release.

One way would be to reincorporate them into OBI.

> OBI currently has a class "data representational model" (Work in
> progress. Currently: alt term data structure, data structure
> specification, definition: "Data representational model is an
> information content entity of the relationships between data items. A
> data representational model is encoded in a data format specification
> such as for cytoscape or biopax.") that we created for the purpose of
> representing the structure data can have. Maybe we should discuss with
> the DENRIE branch on how best to coordinate efforts?

This is clearly in the scope of IAO. I'm leery of further process
discussion. We've got enormous overlap between OBI and the IAO. OBI
folks should buck up and get on with business.

That said, you are of course welcome to initiate anything you want to discuss.

We are thinking about data structure for IAO. I'll bug Jonathan again.
I sent out a note about this on the IAO list recently. The thing to be
careful about is the different between models and structure.

FWIW, I don't think the definition above works well.
I have been meaning to add a qc test that checks for use of obsolete
terms. Will help with cleanup of properties as well.

> To add to the list of "encodings", how do we deal with character
> encoding? (utf-8, latin-1...)

I don't know yet. But following the idea of naming the specifications
(as instances), we can name the specification of the spec that defines
the character sets.

-Alan

[Bjoern Peters]

I strongly favor Alan's suggestion to obsolete these classes in IAO.
Having these 'placeholder' classes in the hierarchy makes navigation of
IAO confusing. I don't think there will be a problem with OBI either, as
we have treated those classes as non-existent during the workshop, and
no 'core terms' rely on them. The OBI terms that subclass them should be
placed under 'information content entity', and reviewed by the Denrie
branch if they should be obsoleted as well.

My $.02

Bjoern

> Digital Quality
> Digital Entity
> Binary Digital Entity
> Binary Executable
> Digital Document
> Text Based Digital Document

The OBI subclasses beneath them are a case in point for obsoleting rather than against. 'digital quality' has been marked as a placeholder for a while. OBI should not subclass those. The OBI classes

--
Bjoern Peters
Assistant Member
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

[Melanie Courtot]

Sorry if I was unclear, I am not advocating against obsoleting those,
they have already been deprecated in the current IAO file (see http://information-artifact-ontology.googlecode.com/svn/trunk/src/ontology/obsolete.owl)

I am merely pointing out that it would be helpful to have a way of
dealing with data, structure and encodings in order to ease transition
on the OBI side when we will want to integrate the next IAO release.
Latest discussion status on the DENRIE branch was about using the
narrative object/report hierarchy in conjunction with the
specification hierarchy to represent our different cases, and maybe
both efforts would benefit from joint discussion.

Melanie

---
Mélanie Courtot
TFL- BCCRC
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada

[Bjoern Peters]

Melanie Courtot wrote:
> Sorry if I was unclear, I am not advocating against obsoleting those,
> they have already been deprecated in the current IAO file (see http://information-artifact-ontology.googlecode.com/svn/trunk/src/ontology/obsolete.owl)
>
>

Sorry, I did misunderstand you. Great that they are going to be gone.

> I am merely pointing out that it would be helpful to have a way of
> dealing with data, structure and encodings in order to ease transition
> on the OBI side when we will want to integrate the next IAO release.
> Latest discussion status on the DENRIE branch was about using the
> narrative object/report hierarchy in conjunction with the
> specification hierarchy to represent our different cases, and maybe
> both efforts would benefit from joint discussion.
>
>

I think that data structure and encoding is clearly IAO scope, not
DENRIE as there is nothing investigation specific about it. Everybody
working on DENRIE interested in it should join the discussion on the IAO
list, but I don't think there is a need to coordinate anything further.
(Which is I guess what Alan wrote below as well).

- Bjoern