Ontology Editor as Library Harmonizer

7/29/2019 Ontology Editor as Library Harmonizer

1/13


2/13

Ont ology Ha rm onizat ion v. 0.5 2004-06-29 2

ru nn ing on a Windows 2000, 32-bit ma chin e. Racershould be started before

att empting a consisten cy check; it r un s in ba ckground a nd is invoked thr ough

Protgby system inter process comm un icat ion. Developmen t of th ese program s

currently (June 2004) is very active, with new Protgbuilds about weekly.

Application to the ALF Sta nda rdA fun damen tal an d limiting cha ra cteristic of Protgor OWL ont ology as a

represent ation of reality is th at it depends on classification an d class membersh ip;

th is kin d of ont ology can not be a pplied where cat egories a re n ot a pplicable, not

kn own, or are not defined un am biguously. In libra ry developmen t, an d in

engineering in genera l, all class members or propert ies are ar tifacts, so this

limitat ion is of no import an ce.

Cla sses in a n ALF Ont ology

To see how an ont ology might be useful in librar y specificat ion a nd developmen t,we star t with a simple example. Racerand Protg(with OWL plugin) were

sta rt ed, an d th e Table of Conten ts for sections 7 an d 8 of th e ALF sp ecificat ion

(IEEE Std 1603-2003) were copied over to define classes for three different ALF

constr ucts: ALF Gener ic Objects (sta tem ent s or declar at ions ), ALF Librar y Objects

(declar at ions only), an d ALF Ann otat ions .

The ontology "class" in OWL is not related to the "class" object in ALF; an OWL

ont ology "class" is closer t o a set in ma th ema tics. Following Knublau ch, et al

(2004), we shall use Courier typeface when ever we writ e th e na me of an OWL

class.

Looking only at the Library classes, the Protg OWL class structure thatresulted is sh own in Fig. 1:


3/13


Figure 1 . Entry of part of the IEEE Std 1603 Table of Conten ts into an

OWL ontology.

The commen ts an d ann ota tions displayed are nonfun ctiona l. Becau se all OWL

classes a re su bclasses ofThing, the Thing class is displayed as necessary for the

ALF_Library class shown selected. In oth er words , an ythin g in OWL necessar ily

is a Thing. The ont ology at t his point is just a first -pass, liter al copy from th e ALFstan dard, an d none of th e under lying ALF relat ionsh ips among th e ALF_Library

classes ha ve been ent ered, or even t hought out, at th is point.

So far , an ontology appear s to be noth ing more t ha n a n outlining represent at ion.

Now let's see how some very basic cons tr ain ts on t he k nowledge repr esent ed can

help k eep th e design of th e ALF s pecificat ion cons isten t.

The classes u nder ALF_Library in F ig. 1 include a Wire and a Blockage. In

actu al cell design, wires a nd blocka ges ar e mu tu ally exclusive objects. Protg

allows th is relat ionsh ip to be ent ered a s a logical disjun ction (mu tu al exclusion) on

th e class es of which they are member s. Selectin g th e Wire class and entering

"Blockage" in t he Disjoint s box shown in th e lower r ight of Fig. 1 mak es Wire and

Blockage mu tu ally exclusive, meaning t ha t no subclass or insta nce in th e ontology

ma y be a joint member of both . IfBlockage were selected now, "Wire"

au tomatically would show up in th e Blockage Disjoin ts box.

Assuming that Antenna and Blockage also are mutually exclusive, we enter

"Blockage" in t he Antenna Disjoint s box. The resu lt, with Blockage selected, is


4/13


sh own in Fig. 2. Protgkeeps t he disjun ctions cons isten t a cross all affected

classes, even though nothing ever was changed or editted in Blockage by th e user.

Figure 2 . The Blockage c lass show s di s junct ions con s i s tent wi th edi t s

made for o ther c lasses .

Notice in Fig. 2 th at Blockage, which is a subclass ofALF_Library, reports tha t

ALF_Library is necessary to it: This just mea ns th at an y element ofBlockage

necessar ily is in ALF_Library, too.

The a bove class s tr uctu re is logically consisten t, as ma y be tested by invoking

Racerusing th e green [?>] butt on in th e middle of the Protgtool bar nea r t he top

of the figures above.

Let us now create an inconsistent class and test it for consistency, just to see how

it work s. Our n ew class will be a kind of a cell.

We select t he Cell class a nd creat e a subclass called BlockWire. Then , by

us ing th e Asser ted Conditions win dow in th e middle of th e figures a bove, we asser t

tha t both Blockage and Wire ar e necessar y to BlockWire; th is is th e same as

saying that BlockWire ha s mu ltiple members hips a nd does not occupy a position in

a hiera rchical tree of classes. Multiple membersh ip is not necessarily an err or; but ,

in th is case, we already have made Blockage and Wire mu tu ally exclusive. If we

now ru n Racer, we find th at our new class BlockWire is inconsisten t in t he presen t

ontology. The Racerreport is shown in Fig. 3.


5/13


Figure 3 . BlockWire i s incons i s tent becau se o f a Dis jo int entered

prev ious ly for Wire, a s revea led by a red out l ine and a R a cer

m es s a g ebo x .

P r op er t ies in a n ALF On t ology

Fixing the Mea nin g of our ALF_Library.

When we creat ed the err oneous BlockWire in t he exam ple above, we said it

would be a kind of cell, so we corr ectly ma de it a k ind ofCell by addin g it a s a class

under Cell. However, th inking about it, Cell isn't a k ind ofALF_Library, so

why is Cell under ALF_Library? Likewise, none of th e classes u nder

ALF_Library in Fig. 1, except possibly SubLibrary, is a kin d of librar y.

Someth ing is wrong here; so, we sh ould ma ke a corr ection.

We certa inly wan t t o keep th e represent ation in corr espondence with th e Std

1603 ta ble of conten ts, so we sh all ret ain th ree ma jor su bclasses ofThing in ourALF ont ology. The easiest corr ection is to chan ge ALF_Library to someth ing

different . Everything un der ALF_Library in F ig. 1 is a kind of object in a n ALF

librar y; so, we decide to corr ect t he t erm inology by ren am ing ALF_Library to

ALF_LibraryObject. As a res ult , our nam ing convention becomes cons isten t with

our ont ology. This kind of consisten cy isn't requ ired by Protg, but it will help us

to avoid fut ur e conceptu al err ors wh ich m ay lead to entr y errors or logical

inconsistencies.


6/13


Adding P roperties

The er ror we just ha ve corr ected was equivalent to th e ont ological err or of

represent ing th e object classes sh own as p r op er t ies in t he r eal world of an

ALF_Library; whereas, th ese classes should ha ve been r epresenting r eal-world

su bcla sses of a class, origina lly misnam ed ALF_Library.

Ap r op er ty is a char acter istic of a class oth er t ha n composition of, or m embers hip

in, th at class. A propert y represent s a relationsh ip among individua ls (insta nces)

which are member s of differen t classes. A propert y ma y be sha red by severa l

classes; h owever, rem oving a pr operty from a class or a class member ha s n o effect

on the identity, or count, of instances or subclasses which are members of that class.

In Protg, properties a re calledslot s for obscur e rea sons; we shall us e only th e

term p r op er ty here.

Fu rt her clarificat ion of th is idea of a pr operty ma y be in order: In m aking th e

correction above, rena min g ALF_Library to ALF_LibraryObject, we decided to

ignore libra ries or k inds of th em in our ontology, an d to work with librar y objects orkinds of th em, instead.

Before th e corr ection, in t he r eal world repr esent ed by the ont ology, addition of a

BlockWire ha d no effect on mem bersh ip in ALF librar ies: No ma tt er h ow man y of

th ese libra ries were in existence, our inconsisten t BlockWire was only a new

propert y of an ALF libra ry.

Now, after th e corr ection, if we added a BlockWire, we would be sa ying tha t, in

th e rea l world, we recognized an increas e by one in th e nu mber of ALF libra ry object

subclasses in existence. In a different sense, BlockWire is special, th ough : We

can not chan ge the n um ber of inst an ces of ALF librar y objects by adding

BlockWire, becau se, logically, BlockWire can not cont ain a n in stan ce, beinginconsistent. Racer, not Protg, forbids t his.

Pr operties ma y be represent ed for an y insta nce in a class, even if th e class does

not happen to include insta nces when th e propert y is assigned. Pr operties are

assigned as propert ies, not a s classes. Protgrequires that a class an d a property

not have the same na me. We sha ll adopt her e the convention of na ming properties

by prepen ding "ha s" to th e corr esponding class na me. Thu s, when Pin is used to

describe a property, it is called th e hasP in propert y. We shall indicat e the na me of

a pr operty by under lining.

Retu rn ing to th e corr ected ALF ontology from F ig. 1, it now consists of th ree

classes ofThing: ALF_GenericObject, ALF_LibraryObject, and Annotation.Th e BlockWire ha s been r emoved.

A class u nder ALF_LibraryObject may be assciated with an oth er class u nder

ALF_LibraryObject to represent a propert y. For example, Pin may be a ssigned

to Cell as a hasPin propert y. The hasPin propert y th en may be viewed as mapping

an inst an ce in Cell to one in Pin. Likewise, Group, from ALF_GenericObject,

ma y be assigned as ha sGr oup; cells typically include ALF vectors a nd port s, so these


7/13


propert ies also may be added. The assignmen ts of th e property nam es may be

made in Protgin t he At Class win dow, as sh own on t he lower r ight of Fig. 4, above

th e Disjoint s window.

Figure 4. Some propert ies o f Cell are adde d in the At Class window .

The n ew properties in Fig. 4 have n o logical function, an d Protgdoes not

automatically associate by root name (Pin and h asPin a re not au tomaticallyass ociat ed), so th ey mean ver y litt le in t he ont ology at th is point .

After addin g the pr opert ies in Fig. 4, a form not sh own h ere (double-click on th e

propert y) ma y be invoked to set t he domain class for ea ch new pr opert y to Cell and

th e ran ge insta nce class to th e corr esponding root-named class. For example, the

domain class of hasGroup is set to Cell, and its r an ge inst an ce class is set to

Group. Group is a su bclass ofALF_GenericObject an d ha s not been ma de visible

in th e figur es shown so far . This mappin g of domain to ra nge is how OW L

propert ies define relationsh ips among instan ces in classes. This mapping gives the

propert ies logical function.


8/13


A Libr a r y Cel l In st a nce in a n ALF On t ology

Now, let u s see h ow a s imple ALF cell model can be repr esent ed in our ont ology.

The cell model, which includes only th e man y-to-ma ny pin t iming ar c for a digita l

device of some kin d, is as follows:

CELL ManyMany1{GROUP AddressBit { 0 : 2 }GROUP DataBit { 1 : 4 }//PIN [2:0] Abus { DIRECTION = input; }PIN [1:4] Dbus { DIRECTION = output; }//

VECTOR ( 01 Abus[AddressBit] -> 01 Dbus[DataBit] ){DELAY = 1.0

{

FROM { PIN = Abus[AddressBit]; }TO { PIN = Dbus[DataBit]; }}

}}

Model 1 . ALF mode l of a man y-to-man y pin t iming a rc for a l ibrary cel l

of type Ma n yMa n y1 . The ce l l layout and funct iona l i ty are omit ted .

The OWL plugin to Protgha s ma ny configura ble ta bs (window ar ra ngements);

th e previous figures sh owed only th e OWL Classes ta b; th e slight ly differen t Classes

an d Insta nces tab adds a window near th e center of th e screen for m an ipulating

insta nces in an ont ology. We sha ll use the Classes an d Instan ces tab in subsequentfigures.

Generic Ins ta nt iation of Man yMany1

We sha ll crea te a n in sta nce in a n ont ology of a completely nonfun ctiona l cell

model, just t o sh ow how it is done. The ALF constr ucts GROUP, PIN, an d

VECTOR already ha ve been assigned as pr operties ha sGroup, hasP in, and

ha sVector of a Cell in our preceding ontology, so all we need do is add a

ManyMany1 subclass t o Cell; th e new class will inher it these properties. To

instantiate a ManyMany1 type of cell, we th en crea te a Direct Ins ta nce for each one,

as shown in Fig. 5. This example sh ows two inst an ces. The paren th esized "(2)" in

th e middle window indicat es th at th ere exist 2 inst an ces ofManyMany1 in the

ont ology. The user has nam ed th ese insta nces ManyMany1_01 and

ManyMany1_02, following typical inst an ce-nam ing pra ctice in a n r egist er-tr an sfer

level (RTL) net list. We sh all us e boldfaced typeface to indicate inst an ces.


9/13


Figure 5 . Creat ion o f two ins tances o f the ce l l c lass ManyMany1. The

ins tances have been name d, ManyMany1_01 and ManyMany1_02 .

All At Class pr operties shown in F ig. 5 are in herited a nd t hu s ar e displayed by

Protgun colored. The class ManyMany1 represent s almost n oth ing of the cont ent

visible in Model 1, so we mu st do some more work to repr esent timin g in our

ont ology; wha tever we do to th e class , also will be done to an y inst an ce of it.

Complete Ont ology for t he Ma nyMan y1 Libra ry Model

Stu dying Model 1, an d recognizing th at th e cur ren t ALF ont ology includes Group,Pin, and Vector, we sh all pr oceed by deriving su bclasses of th ese classes s pecific to

ManyMany1 an d then mak ing the derived classes necessar y to ManyMany1.

Fir st, we go for t he first t ime to ALF_GenericObject. We kn ow th at every ALF

GROUP mu st h ave a domain, so we add a n integer, multiple-value propert y,

ha sDomain, to the Group class th ere. We th en creat e a subclass ofGroup called

ManyMany1_Group, which will be specific to our cell. Becaus e th e Model 1 model

cont ains two ALF GROUPs, each with different para meters , we'll fur th er der ive two

classes ofManyMany1_Group, ManyMany1_AddressBit_Group and

ManyMany1_DataBit_Group. By ass igning Model 1 ha sDomain values in these

latter classes, we can inst an tiat e them as th e GROUPs AddressBit and DataBi t inour cell.

The hasDomain properties will be integer types, allowed to take on multiple

values, in th is case, one for th e left, an d th e oth er for th e right, index nu mber.

After as signing th e values from Model 1, th e resu lt is shown in F ig. 6.


10/13


Figure 6 . Subclasses and propert ies o f ManyMany1_Group are created

for the Group contr ibut ion to the t iming-arc onto logy o f ManyMany1.

The symbol us ed in th e Asser ted Conditions expr essions is from th e Protghelp

menu as sh own in F ig. 7.

Figure 7 . AP r otg help men u l i s ts the log ica l operators a l lowe d wh en

relat ing OWL properties to c lasses .

Having completed the Group propert ies, we may retu rn t o ALF_LibraryObject

an d similarly extend Pin. Every pin sh ould ha ve a direction, so we add a

correspondin g propert y to our Pin class. There ha ppens to be an ALF_Annotation

class Direction, so we sha ll use th at class as a pr operty r an ge for ha sDirection; we

create for Direction only two ins ta nces, input and output , becau se tha t is all

Model 1 requ ires. We can extend Direction to meet th e ALF sta nda rd later , if

necessar y. We also add a hasP inSlice property to represent t he bus indices, if an y,

for a pin.


11/13


With t he At Class propert ies of a Pin defined, we crea te a new su bclass called

ManyMany1_Pin, for our model; th en, for t his class, we creat e two oth er s ubclasses,

ManyMany1_Abus_Pin and ManyMany1_Dbus_Pin, to represent t he t wo kinds of

pin appearin g in Model 1. We th en can inst an tiat e Abus and Dbus to denote th e

Model 1 pins. After associatin g th e var ious pr opert y values, th e resu lt is shown in

Fig. 8.

Figure 8 . Subclasses and propert ies o f ManyMany1_Pin for the th e

timing arc onto logy for Model 1 . The M superscr ipt is because those

c lasses have mul t ip le nece ssary c lasses , in th i s case , ManyMany1_Pin

a n d Direction.

There rema ins the most complicat ed statemen t in Model 1, th e VECTOR. Our

ont ology only repr esent s a t iming ar c, so we begin by creat ing just one su bclass of

Vector named TimingVector. The delay stat ement an d th e vector expression

edge types seem t o be th e only u nique th ings in Model 1, so we creat e th e following

data type propert ies At Class TimingVector: ha sDelay, hasToEdgeType, and

ha sFr omE dgeType. The edgetype alt ern at ives will be enu mer at ions allowing just

one of two str ings, "01" or "10", for presen t pu rposes. We can us e class referen ces

for th e ra ma inder , so we crea te t he following object pr opert ies At Clas s

TimingVector: ha sToPin, hasF romPin, hasToPinGroup, and ha sFr omPin Group.

The VECTOR in Model 1 is not nam ed, an d we do not instan tiate it. The result

is shown in Fig. 9.


12/13


Figure 9 . Subclasses and propert ies to add ManyMany1_TimingVector.

Fin ally, to ass ociat e ManyMany1_TimingVector with ManyMany1, we mak e

ManyMany1_TimingVector a necessar y condit ion of it. We do th e same with ea ch

class above th at cont ains an insta nce or propert y necessary t o define th e timing ar c.

.

Figure 10 . The completed ManyMany1 onto logy .


13/13


Our final ont ology is shown in Fig. 10. The form u sed to ma ke the ha sGroup

insta nce ra nge assignment also is shown. Notice th at Protgha s copied

ManyMany1 as a subclass of its various necessary classes automatically.

Closing N oteThe softwar e cur ren tly available is beta-test quality, and its featur es ar e

incompletely implement ed at t his writing. In gener al, th ere are limitat ions in

qua nt ifying class pr opert ies (qua nt ificat ion in t he a rit hm etical, not form al-logical,

sense) an d in ordina l relations such as great er-than . Pr esuma bly, th is kind of

limitat ion will be lifted in comin g mont hs , an d Protg-based OWL will be usable in

represent ing an EDA library.

References

(Available a t http://protege.stanford.edu/plugins/owl/documentation.html)

Knublau th , Holger, Dameron, Olivier, and Musen, Mark A. "Weaving th e

Biomedical Seman tic Web with th e Pr otg OWL Plugin".

Horridge, Matt hew. A Practica l Gu id e T o B u ild in g OW L On tologies With T he

Protege-OWL Plugin (v. 1.0).

Documents

Ontology Editor as Library Harmonizer