When I first began
developing ontologies it seemed reasonable to define properties
for each of the classes I'd defined in the class hierarchy. It
seemed kinda cute that reasoning software could infer the type of
an object in a statement by reference to the statement predicate's
rdfs:range. No runtime examination of rdf:type of the object and
its superclasses. Faster and cheaper it seemed and better too
because this was 'inference' at work. To boot, there were property
hierarchies right along with class hierarchies, so let's go! Just
take the class name, prefix it with 'has', and presto, no more
thought needed! Ergo, jmc:hasOntology was born!
You bet this was absurd. I began to doubt the utility of
duplicated hierarchies. Documentation became repetitive. User
interfaces began to look like endless three-column tables of
labels, autocompletes, and help blurbs. And I began to loathe
adjustments to the class hierarchy -- the ripple effects were
starting to crash like waves. In other words, 'semantic'
applications began to look a helluva lot like RDB applications.
The only justification for this effort became the elimination of
stodgy fixed-table relational databases.
My epiphany began with simple arithmetic. I wanted to store a
current value ("hasAddress"), a previous value ("hadAddress") and
a future value ("willHaveAddress"). Jeez I realized things could
get out of hand here if everyone wanted to do this not-so-crazy
thing. Looking at other RDF ontologies I began to see I was hardly
alone in the design pattern I had instinctively adopted. And when
I looked at FOL properties, I saw that some were
just verbs,
like one I had privately cherished but fearfully did not use:
"is-a". Instead, I used "rdf:type", itself quizzical to me since
it seemed more rational to define Types, not Classes, you know, to
maintain that good-old consistency between a property name and its
rdfs:range. But, but. Wait. Hmm...
This memo asserts that our industry can
benefit enormously if Ontology Designers are constrained in the
main to definitions of Class hierarchies (and Individuals). It
claims a fixed set of relation properties must be normatively
defined. Finally, it claims that whenever possible, resource names
should follow a normative pattern. As a unit, this is a *
semantic
protocol* that eliminates the gobbledygook now overwhelming
our most earnest efforts to create reusuable quality ontologies.
Accordingly, I propose the 2014 Communique call for establishing a
semantic protocol as an
etiquette
(
the customary code of polite behavior in society or
among members of a particular profession or group).
Relation properties. First-order logic requires
predicates to be verbs; this rule is applied only to
object properties, not to text properties. All relation
properties are formulated according to the following patterns.
- verb:preposition -- this is used for
(indirect) objects of prepositions
- verb:a -- this is used for existential statements
- verb:this -- this is used for individuated (direct)
objects
- verb:some -- this is used for non-individuated
(direct) objects
There are about 100 prepositions. Verbs may be of the usual
tenses, existential, deontic and or negative. Verb auxiliaries are
connected using dashes. No upper casing is allowed (camel-casing
is specifically forbidden). 'Subproperty' relations do exist among
these properties while adverbial subproperties are anticipated. It
is suggested the initial set of verbs consist of two groups: "is"
and "has" -- existentials and possessives, essential concepts in
object oriented design/programming.
Resource names. To the extent appropriate to application
contexts, resource names whether actual or artificial, should be
prefixed by an operative type for the resource, e.g., Person:Obama
is a resource as is President:Obama a resource. Specifically, this
'type' is meant in an ISO manner, i.e., as a type of
topic
not necessarily as an existential type; this means that for
instance President:Obama is:this Person:Obama, and or Person:Obama
is:this President:Obama, both individual topics connoting
different contexts and different models while often denoting a
single more comprehensive 'resource'.
Axioms. I am no expert here, but I believe normative
axioms are to be created relative to a selected published
definition of a property, for the default use case. For example,
the axioms for 'be:of' may be quite different than those for
"is:of". Secondly, of central importance is that axiomatic
specializations can occur for pairs of subject-type and
object-type; these are not 'subproperties' in any sense -- at most
these are
unnamed contextual properties.
Example. The objects below of course can be URLs (I think
in terms of wikipages).
Event:X
be:a Type:Event
is:a Type:Teleconference
is:on Date:20140113
is:from Time:0930PST
is:until Time:11:15PST
may-be:until Time:1200PST
is:by Organization:Ontolog
is:on Device:Telephone
is:at HTTP://ontolog.cim3.net/cgi-bin/
has:this Name:Conference Call 2014 01 23
has:this Title:OntologySummit2014 session-02 Track-A: Common
Reusable...
has:this Theme:Big Data and Semantic Web Meet Applied
Ontology
has:this Focus:Track-A: Common Reusable Semantic Content
has:this Topic: Use and Reuse of Semantic Content
has:this Co-chair:Mr. MikeBennett
has:this Co-chair:Ms. AndreaWesterinen
has:this Presenter:Dr. GaryBergCross (SOCoP)
has:this Briefing:Use and Reuse of Semantic Content
is:as-of Timestamp:20140112T0922EST
is:per Person:Peter Yim
Thanks for reading this far.
/jmc