Upload
john-michael-williams
View
222
Download
0
Embed Size (px)
Citation preview
7/29/2019 Ontology Editor as Library Harmonizer
1/13
7/29/2019 Ontology Editor as Library Harmonizer
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:
7/29/2019 Ontology Editor as Library Harmonizer
3/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 3
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
7/29/2019 Ontology Editor as Library Harmonizer
4/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 4
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.
7/29/2019 Ontology Editor as Library Harmonizer
5/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 5
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.
7/29/2019 Ontology Editor as Library Harmonizer
6/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 6
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/29/2019 Ontology Editor as Library Harmonizer
7/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 7
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.
7/29/2019 Ontology Editor as Library Harmonizer
8/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 8
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.
7/29/2019 Ontology Editor as Library Harmonizer
9/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 9
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.
7/29/2019 Ontology Editor as Library Harmonizer
10/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 10
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.
7/29/2019 Ontology Editor as Library Harmonizer
11/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 11
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.
7/29/2019 Ontology Editor as Library Harmonizer
12/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 12
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 .
7/29/2019 Ontology Editor as Library Harmonizer
13/13
Ont ology Ha rm onizat ion v. 0.5 2004-06-29 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).