On 3/11/15 10:40 AM, John Bottoms
JohnS, et al,
I got interested in the origin of the ABox/TBox and went to
wikipedia. In the process I discovered how much CS has
surrendered to industry.
On Wikipedia there is a brief nod to DL on the origins of the
terms. The earliest reference does not mention ABox/TBOx and the
bulk of the references are 5 to 10 years after the earliest
reference. Most of the references immediately jump to a
particular language or implementation. The theory is little
discussed. The page is commented by a community editor as
lacking in true references.
It may be that the notion of "TheBoxes" has diminished in the
face of Design Patterns, and more specifically of containers and
ontological notation. I don't understand why these particular
data structures are not included with well known data
structures. In my recent work I have segregated this discussions
into layers and the layer for containers is referred to as syntactic
while the labels of containers, the slot names, are
identified as semantics. This is more in line with
Dijkstra's layered architecture of "T.H.E. Machine".
Given that the Wikipedia page discusses ABox and TBox, I'm not
convinced that that the definition is sufficient. It says, "TBox
statements describe a conceptualization, a set of concepts and
properties for these concepts" and "Together ABox and TBox
statements make up a knowledge base". Is this sufficient?
Further, there is no discussion of the data types within these
I still lean toward the community development of a lexicon and a
basic slot structure and related jargon.
This is one of those showcases for Linked Open Data, Identity, and
ACLs i.e., a document that has many curators based verifiable
identity and read-write interactions over HTTP. Basically, we
should be able to collectively curate a glossary of terms, without
being impeded by the futile pursuit of global consensus.
I built such a glossary  out of frustration. It has since
morphed into something published officially by OpenLink .
For a personal standpoint, I see the terms TBox, ABox as
colloquialisms that are just as problematic a the term Graph. All
of the aforementioned terms are confusion vectors. You can speak
sensibly about Data, Relations, Semantics, and Entity
Relationships without ever using any of those colloquialisms.
Our industry is surrendering the discipline of terminology,
description, and knowledge to those that learn from the bottom-up
(which is how colloquialisms of this kind emerge). For instance, I
suspect that someone might have once sketched out some relations
that represent the nature of entities in some realm, using a box
labelled "Terms or Terminology" and then repeated the activity
pattern where the relations represent actual assertions about
said entities that was labelled "Assertions" -- leading to the
TBox and ABox colloquialism.
Presently, there are several
definitions of "ontology" and some are insufficient.
There will always be multiple definitions for
a variety of reasons (good, bad, and outright ugly). That said,
none of these definitions will successfully skirt around the fact
that in any realm of comprehension you must have: entity types,
relationship types, entities.
I still don't know who coined the terms ABox and TBox.
-- My Glossary of Terms
 https://github.com/kidehen/GlossaryOfTerms -- Github project
OpenLink Official Edition.
Founder & CEO
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Description: S/MIME Cryptographic Signature
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)