Escolar Documentos
Profissional Documentos
Cultura Documentos
Tutorial Owl
Tutorial Owl
Um guia prtico de
construo de ontologias
OWL
plug-in Protege-OWL 3.4
Original traduzido e adaptado:
HORRIDGE, M. et al. A Practical Guide To Building OWL Ontologies using the Protege-OWL
plugin and CO-ODE Tools, Edition 1.0. (2004). Available from Internet:
<http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf>. Access: 20 June
2005.
Referncia da traduo:
HORRIDGE, M. et al. Um guia prtico para a construo de ontologias OWL, plugin
Protg-OWL 3.4. Trad. SOARES, D.R.; ALMEIDA, M.B. Disponvel na Internet
<www.eci.ufmg.br/mba/>, 2008. 100p. (Original ingls).
Julho de 2008
2 of 83
SUMRIO
1.INTRODUO
1.1)CONVENES
2.REQUISITOS
3.O QUE SO AS ONTOLOGIAS OWL?
3.1)AS TRS ESPCIES DE OWL
3.1.1)OWL-Lite
3.1.2)OWL-DL
3.1.3)OWL-Full
3.1.4)A escolha da sub-linguagem
3.2)COMPONENTES DA ONTOLOGIA OWL
3.2.1) Individuals (Indivduos)
3.2.2)Properties (Propriedades)
3.2.3)Classes (Classes)
4.CONSTRUO DE UMA ONTOLOGIA OWL
4.1)CRIAO DE CLASSES
4.2)CLASSES DISJUNTAS
4.3)USO DO ASSISTENTE OWL PARA CRIAR CLASSES
4.4)PROPRIEDADES OWL
4.5)PROPRIEDADES INVERSAS
4.6)CARACTERSTICAS DAS PROPRIEDADES OWL
4.6.1)Propriedades funcionais
4.6.2)Propriedades funcionais inversas
4.6.3)Propriedades transitivas
4.6.4)Propriedades simtricas
4.7)DOMAINS (DOMNIOS) E RANGES (ESCOPO) DE UMA PROPRIEDADE
4.8)DESCRIO E DEFINIO DE CLASSES
4.8.1) Restries de propriedades
4.8.2)Restries existenciais
4.9)USO DE UM MI-MECANISMO DE INFERNCIA (REASONER)
4.9.1)Determinao a sub-linguagem OWL
4.9.2)Uso do RACER
4.9.3)Funcionamento do MI
4.9.4)Classes inconsistentes
4.10)CONDIES NECESSRIAS E SUFICIENTES (CLASSES PRIMITIVAS E DEFINIDAS)
4.10.1)Classes Primitivas e definidas
4.11)CLASSIFICAO AUTOMTICA
4.11.1)Resultados da classificao
4.12)RESTRIES UNIVERSAIS
4.13)CLASSIFICAO AUTOMTICA E OWR-OPEN WORLD REASONING (RACIOCNIO DE MUNDO ABERTO)
4.13.1)Axiomas de fechamento
4.14)PARTIES DE VALOR
4.14.1)Axiomas de Cobertura
4.15)O PROPERTY MATRIX WIZARD (ASSISTENTE MATRIZ DE PROPRIEDADE)
4.16)RESTRIES DE CARDINALIDADE
5. MAIS SOBRE OWR-OPEN WORLD REASONING (RACIOCNIO DE MUNDO ABERTO)
6.OUTRAS CONSTRUES OWL NO PROTEGE-OWL
6.1)CRIAO DE INDIVDUOS
6.2)RESTRIES HASVALUE (TEMVALOR)
6.3)CLASSES ENUMERADAS
6.4)PROPRIEDADES DE ANOTAO (ANNOTATION PROPERTIES)
6.5)CONJUNTOS MLTIPLOS DE CONDIES NECESSRIAS E SUFICIENTES
7.OUTROS TPICOS
3 of 83
7.1)PERFIL DA LINGUAGEM
7.2)NAMESPACES E IMPORTAO DE ONTOLOGIAS
7.2.1)Namespaces
7.2.2)Criao e edio de namespaces no Protege-OWL
7.2.3)Importao de ontologias em OWL
7.2.4)Importao de ontologias no Protege-OWL
7.2.5)Importao da ontologia Dublin Core
7.2.6)Protege-OWL Metadata Ontology (Ontologia de metadados do Protege-OWL)
7.3)TESTES EM ONTOLOGIAS
7.4) TODO LIST (LISTA DE TAREFAS A FAZER)
APNDICE A
A.1 RESTRIES DE QUANTIFICAO
A.1.1 someValuesFrom Restries Existenciais
A.1.2 allValuesFrom Restries Universais
A.1.3 Combinao de restries Existenciais e Universais na descrio de classes
A.2 RESTRIES HASVALUE
A.3 RESTRIES DE CARDINALIDADE
A.3.1 Restries de cardinalidade mnima
A.3.2 Restries de cardinalidade mxima
A.3.3 Restries de cardinalidade exata
A.3.4 UNA-Unique Name Assumption (Presuno de nome nico) e cardinalidades
APNDICE B
B.1 CLASSES INTERSEO ()
B.2 CLASSES UNIO ()
4 of 83
LISTA DE EXERCCIOS
Exerccio 1: faa o seguinte:
Exerccio 2: criar um exemplo de projeto
Exerccio 3: criao das classes pizza, pizzatopping e pizzabase
Exerccio 4: tornar disjuntas as classes pizza, pizzatopping e pizzabase
Exerccio 5: use o assistente create multiple classes (criar mltiplas classes) para criar thinandcrispy (finaecrocante) e
deeppan (basegrossa) como subclasses de pizzabase
Exerccio 6: criao de recheios para pizzas
Exerccio 7: criar uma propriedade de objeto chamada hasingredient
Exerccio 8: criao de subpropriedades de hasingredient: hastopping e hasbase
Exerccio 9: criao de propriedades inversas
Exerccio 10: tornar hasingredient (temingrediente) uma propriedade transitiva
Exerccio 11: tornar funcional a propriedade hasbase
Exerccio 12: especificar range (escopo) da relao hastopping
Exerccio 13: especificar domnio da propriedade hastopping como pizza
Exerccio 14: especificar domain (domnio) e range (escopo para istoppingof
Exerccio 15: especifique domain (domnio) e range (escopo) para a propriedade hasbase (tembase) e a sua propriedade
inversa isbaseof (basede)
Exerccio 16: adicionar restrio a pizza de forma que pizza tenha uma pizzabase
Exerccio 17: adicione restrio a pizza especificando que pizza deve ter uma pizzabase
Exerccio 18: criar uma subclasse de pizza chamada namedpizza, e uma subclasse de namedpizza chamada margheritapizza
Exerccio 19: criar uma restrio existencial (E) para a classe margheritapizza, a propriedade hastopping e o filler
mozzarellatopping, para que uma margheritapizza tenha pelo menos um mozzarellatopping.
Exerccio 20: criar uma restrio existencial (E) para a classe margheritapizza, a propriedade hastopping e o filler
tomatotopping, para que uma margheritapizza tenha pelo menos um tomatotopping
Exerccio 21: clonar e modificar a descrio de margheritapizza
Exerccio 22: criar classes americanhotpizza e sohopizza
Exerccio 23: tornar disjuntas as subclasses de namedpizza.
Exerccio 24: adicionar uma probe class denominada probeinconsistenttopping como subclasse de cheesetopping e de
vegetable
Exerccio 25: verificao de inconsistncia de probeinconsistenttopping
Exerccio 26: remoo de declarao disjunta de cheesetopping e vegetabletopping
Exerccio 27: correo da ontologia com a disjuno entre cheesetopping e vegetable
Exerccio 28: criao de subclasse de pizza chamada cheesypizza, com pelo menos um recheio que um tipo de
cheesetopping
Exerccio 29: converso de condies necessrias de cheesypizza em condies necessrias e suficientes
Exerccio 30: uso do mi para computar automaticamente a subclasse de cheesypizza
Exerccio 31: criao de classe para descrever vegetarianpizza (pizza vegetariana)
Exerccio 32: converso das condies necessrias de vegetarianpizza em condies necessrias e suficientes
Exerccio 33: uso do mi para classificar a ontologia
Exerccio 34: adio de axioma de fechamento propriedade hastopping para margheritapizza
Exerccio 35: adicio de axioma de fechamento a propriedade hastopping para sohopizza
Exerccio 36: criao automatica de axioma de fechamento na propriedade hastopping para americanapizza
Exerccio 37: criao automatica de axioma de fechamento para a propriedade hastopping de americanhotpizza
Exerccio 38: usao do mi para classificar a ontologia
Exerccio 39: criao de um valuepartition para representar o spiciness ("tanto"de pimenta) em recheios de pizza
Exerccio 40: uso do assistente matriz de propriedade para especificar o tempero de recheios de pizza
Exerccio 41: criao de uma classe spicypizza como uma subclasse de pizza
Exerccio 42: uso do mi para classificar a ontologia
Exerccio 43: criao de interestingpizza (pizza interessante) com pelo menos 3 recheios.
Exerccio 44: uso do mi para classificar a ontologia
Exerccio 45: criao de nonvegetarianpizza , subclasse de pizza e disjunta de vegetarianpizza
Exerccio 46: nonvegetarianpizza complemento de vegetarianpizza
Exerccio 47: adico de pizza a condies necessrias e suficientes nonvegetarianpizza
Exerccio 48: uso do mi para classificar a ontologia
Exerccio 49: criao de subclasse de namedpizza com recheio de mozzarella
Exerccio 50: uso do mi para classificar a ontologia
Exerccio 51: criao da classe country (pas) e insero de indivduos
Exerccio 52: criao da restrio hasvalue para especificar que mozzarellatopping tem italy como pas de origem.
5 of 83
6 of 83
1.Introduo
O presente guia descreve a criao de ontologias utilizando o editor de ontologias Protege associado ao
Plug-in Protege-OWL. Apresenta-se brevemente a linguagem OWL-Ontology Web Language, uma
linguagem baseada em Lgica Descritiva, e enfatiza-se a construo de ontologias OWL-DL. Utiliza-se um
MI-Mecanismo de Inferncia (reasoner) baseado em Lgica Descritiva para verificar a consistncia da
ontologia e para computar automaticamente a hierarquia de classes. Alm disso, descrevem-se constructos
OWL, tais como a restrio temValor e Classes Enumeradas, descrevem-se namespaces, importao de
ontologias, caractersticas e funcionalidades da ferramenta Protege-OWL.
1.1)Convenes
Os exerccios so apresentados da seguinte forma:
2.Requisitos
Para seguir este tutorial necessrio instalar no mnimo o Protege 3.4, o plug-in Protege-OWL e tambm o
plug-in OWL-Wizards, disponveis na Web em http://protege.stanford.edu/.
Recomenda-se (opcional) o plug-in OWLViz, que permite visualizar as declaraes e inferncias obtidas. Os
passos para instalao so documentados. Finalmente, necessrio ter um DIG-Description Logics
Implementaters Group compatvel com o MI instalado, o que permite computar as relaes de subsuno
entre as classes e detectar inconsistncias. Recomenda-se o uso do MI denominado RACER, o qual est
disponvel na Internet.
7 of 83
8 of 83
3.2.2)Properties (Propriedades)
Propriedades so relaes binrias (relaes que contm duas coisas) entre indivduos, ou seja, as
propriedades ligam dois indivduos. Por exemplo, a propriedade hasSibling (temIrmo) pode ligar o
indivduo Matthew ao indivduo Gemma; ou a propriedade hasChild (temCriana) pode ligar o indivduo
Peter ao indivduo Matthew. As Propriedades podem tambm ser inversas. Por exemplo, a propriedade
inversa de hasOwner (temDono) isOwnedBy (PropriedadeDe). As propriedades podem limitar-se a um
valor nico: so as Functional Properties (propriedades funcionais). Elas tambm podem ser Transitive
Properties (Propriedades transitivas) ou Symetric Properties (Propriedades Simtricas). Estas
caractersticas das propriedades so detalhadas adiante. A FIG. 3.2 mostra propriedades que conectam
indivduos.
9 of 83
10 of 83
3. A janela do Protege aberta e as tabs se tornam visveis. Um novo projeto sempre aberto na viso
Metadata (Metadados).
11 of 83
importante salvar o projeto, o que permite encerrar as atividades quando conveniente. Para salvar o
projeto sigas as instrues abaixo:
1. Clique no boto Save Project (Salvar Projeto), o terceiro da esquerda no menu superior do Protege.
Pode-se escolher tambm Save project (Salvar Projeto) no menu File (Arquivo). A caixa de dilogo
Protege Files (Arquivos do Protege) aberta.
12 of 83
Nota: Pode-se tambm escolher uma localizao digitando o caminho completo na linha Project (Projeto).
Os nomes dos outros arquivos sero preenchidos automaticamente.
4.1)Criao de classes
A janela principal do Protege consiste de tabs (etiquetas) que apresentam caractersticas do base de
conhecimento. A etiqueta mais importante que surge ao se iniciar um projeto a etiqueta Classes. Em geral,
classes correspondem a objetos, ou a tipos de objetos no domnio. Por exemplo, em um jornal, as classes
podem ser pessoas, tais como editores, reprteres e vendedores; componentes do layout do jornal, tais
como sees; e contedo do jornal, tais como anncios e artigos.
As classes no Protege so mostradas em uma hierarquia com heranas e apresentadas em um Class Browser
(Navegador de Classes) do lado esquerdo da etiqueta Classes. As propriedades da classe selecionadas no
momento so apresentadas no Class Editor (Editor de Classes), direita.
Nessa seo, o objetivo criar classes e subclasses, modificar a hierarquia de classes, criar classes abstratas, e
adicionar superclasses adicionais a classes j existentes.
Uma nova ontologia contm uma classe chamada owl:Thing. Conforme mencionado, as classes OWL so
interpretadas como conjuntos de indivduos (ou conjunto de objetos). A classe owl:Thing a classe que
representa o conjunto que contm todos os indivduos, uma vez que todas as classes so subclasses de
owl:Thing.
13 of 83
DICA = Apesar de no existir uma regra obrigatria para nomear classes OWL, recomenda-se
que todos os nomes de classes iniciem com letra maiscula e no contenham espaos. Este tipo
de notao conhecida como CamelBack. Por exemplo: Pizza, PizzaTopping, MargheritaPizza.
Pode-se usar o underscore ( _ ) para juntar palavras. Por exemplo, Pizza_Topping. A regra
importante para a consistncia da ontologia.
14 of 83
4.2)Classes disjuntas
Tendo adicionado as classes Pizza, PizzaTopping e PizzaBase, preciso agora dizer que estas classes so
disjuntas, de modo que um indivduo (ou objeto) no poder ser instncia de mais de uma dentre as trs
classes. Para especificar as classes que sero disjuntas da classe selecionada, use a forma grfica Disjoints
(Disjuno), localizada no canto inferior direito da etiqueta OWLClasses.
Create disjoint class from OWL expression (criar classe disjunta para expresso OWL)
Add disjoint class (adicionar classe disjunta)
Add all siblings (adicionar todas as classes irms)
Remove all siblings (remover todas as classes irms)
Delete selected row (apagar linha selecionada)
Tabela 3: botes da interface Disjoints
Observe que a interface Disjoint (Disjuno) agora exibe as classes PizzaTopping e PizzaBase. Selecione a
classe PizzaBase e note a interface Disjoint exibe agora as classes que disjuntas para PizzaBase, ou seja,
Pizza e PizzaTopping.
SIGNIFICADO = Considera-se que as classes OWL se sobrepem. Por isso, no se pode
assumir que um indivduo no um membro de uma classe especfica, simplesmente porque no
se declarou que ele um membro daquela classe. Para desconectar um grupo de classes
preciso torn-las disjuntas. Isto garante que um indivduo que tenha sido declarado como sendo
membro de uma das classes do grupo, no pode ser um membro de nenhuma outra classe
naquele mesmo grupo. No exemplo (Pizza, PizzaTopping e PizzaBase) a disjuno foi realizada,
o que significa que no possvel a um indivduo ser membro de uma combinao destas
classes. No faz sentido um indivduo ser uma Pizza e uma PizzaBase.
15 of 83
16 of 83
6. Clique no boto Next no assistente. Selecione a opo Make all primitive siblings disjoints? (Marcar
todas as irms primitivas como disjuntas?). Ao invs de utilizar a interface das classes disjuntas, o
assistente tornar as novas classes disjuntas automaticamente.
7. Clique no boto Next para visualizar e adicionar anotaes. Em geral, as anotaes so usadas para
gravar dados sobre a edio da ontologia: quem e quando a criou, quando foi revisada, etc. As anotaes
bsicas de propriedades OWL so selecionadas por default. Nenhuma dado ser informado nesse momento.
Pressione Finish.
DICA = caso tenha sido importada a ontologia DC-Dublin Core (mais detalhes adiante), as
propriedades de anotao DC podem estar disponveis para anotao das classes no passo 7 do
exerccio 5. O DC um conjunto de metadados, que pode ser usado para anotaes em
ontologias de dados tais como creator (criador), date (data), language (lngua), etc.
Depois de pressionar Finish, o assistente cria as classes, as torna disjuntas, e as seleciona na etiqueta
OWLClasses. A ontologia tem ThinAndCrispyBase e DeepPanBase como subclasses de PizzaBase. Essas
novas classes so disjuntas, e por isso, a BasePizza (base da pizza) no pode ser uma ThinAndCrispyBase
(base fina e torrada) e uma DeepPanBase (base grossa) ao mesmo tempo. No caso de muitas classes a
adicionar, o assistente acelera o processo.
DICA = na segunda tela do assistente (Create Multiple Subclasses), as classes so criadas e
inseridas. Caso existam muitas classes a criar com o mesmo prefixo ou sufixo, possvel usar as
opes de auto-anexar no incio e auto-anexar no final em conjunto com os nomes de classes
inseridos.
17 of 83
SIGNIFICADO = At agora, foram criado classes nomeadas simples, algumas das quais so
subclasses de outras. A construo da hierarquia de classes pode parecer intuitiva. Contudo, o
que realmente significa ser subclasse de alguma coisa em OWL? Por exemplo, o que significa
18 of 83
Figura 4.9: O significado de ser uma subclasse - todos os indivduos que so membros da classe
TomatoTopping so membros da classe VegetableTopping e PizzaTopping, uma vez que se estabeleceu
que TomatoTopping subclasse de VegetableTopping, que por sua vez subclasse de PizzaTopping.
4.4)Propriedades OWL
As propriedades OWL representam relacionamentos entre dois indivduos. Existem dois tipos principais de
propriedades: Object Properties (Propriedades de Objeto) e DataType Properties (Propriedades de Tipos
de Dados). As Object Properties (Propriedades de Objeto) conectam um indivduo a outro indivduo. As
DataType Properties (Propriedades de Tipos de Dados), por sua vez, conectam um indivduo a um valor
do XML-Schema Datatype (disponvel em http://www.w3.org/TR/xmlschema-2/) ou a um literal do
RDF-Resource Description Framework (disponvel em http://www.w3.org/TR/rdf-primer/).
O OWL tambm tem um terceiro tipo de propriedade, denominada Annotation Property (Propriedade de
Anotao), as quais so usadas para adicionar metadados as classes, aos indivduos e as Object Properties
(Propriedades de Objeto) e as DataType Properties (Propriedades de Tipos de Dados). A FIG. 4.10
apresenta um exemplo de cada tipo de propriedade.
19 of 83
As propriedades podem ser criadas usando a etiqueta Properties (Propriedades), mostrada na FIG. 4.11.
Para criar propriedades OWL a partir etiqueta Properties da utilize o boto localizado no canto superior
esquerdo. Como se pode ver na FIG. 4.13, existem botes para criao de propriedades de tipos de dados,
propriedades de objeto e propriedades de anotao. A maioria das propriedades criadas neste tutorial so
propriedades de objeto.
Pode-se tambm pode criar propriedades a partir da etiqueta OWLClasses, usando a interface Properties,
apresentada na FIG.4.12.
20 of 83
de classe. Ela ativada quando o cursor colocado sobre a descrio da classe na interface do
usurio.
21 of 83
4.5)Propriedades Inversas
Uma propriedade de objeto tem uma propriedade inversa correspondente. Se um propriedade liga um
indivduo "a" a um indivduo "b", ento a propriedade inversa correspondente liga o indivduo "b" ao
indivduo "a". Por exemplo, a FIG. 4.16 mostra a propriedade hasParent (temPais) e sua propriedade
inversa hasChild (temFilho): se Matthew hasParent Jean, da propriedade inversa pode-se inferir que Jean
hasChild Matthew.
Figura 4.16: exemplo de propriedade inversa: hasParent tem com inversa hasChild
22 of 83
propriedade isBaseOf (BaseDe) foi criada como subpropriedade de isIngredientOf. Isto ocorre porque
hasBase (temBase) uma subpropriedade de hasIngredient (temIngrediente), e isIngredientOf
(IngredienteDe) a propriedade inversa de hasIngredient (temIngrediente).
5. Selecione a propriedade hasTopping (temRecheio).
6. Pressione o boto Create new inverse property (Criar uma nova propriedade inversa) na interface
Inverse Property (Propriedade Inversa). Na caixa de dilogo apresentada, renomeie a propriedade
isToppingOf (RecheioDe). Feche a caixa de dilogo e observe que isToppingOf (RecheioDe)
sub-propriedade de isIngredientOf (IngredienteDe).
A hierarquia de propriedades deve parecer com a FIG. 4.18. Observe a seta bidirecional que indica a
propriedade inversa.
4.6.1)Propriedades funcionais
Se uma propriedade funcional, para um determinado indivduo 1, pode existir at no mximo um
indivduo 2 que est relacionado ao indivduo 1 atravs dessa propriedade. A FIG. 4.19 apresenta um
esquema de exemplo para a propriedade funcional hasBirthMother (TemMeBiolgica): algum s pode
nascer de uma nica me. Se Jean hasBirthMother Peggy, e Jean hasBirthMother Margaret, ento
hasBirthMother uma propriedade funcional, ou seja, Peggy e Margaret so mesma pessoa. Contudo,
observe que se Peggy e Margaret so descritos explicitamente como duas pessoas diferentes, ento as
afirmaes anteriores levam a uma inconsistncia.
23 of 83
4.6.3)Propriedades transitivas
Se uma propriedade P transitiva relaciona o indivduo "a" ao indivduo "b", e tambm um indivduo "b" ao
indivduo "c", infere-se que o indivduo "a" est relacionado ao indivduo "c" atravs da propriedade P. Por
exemplo, a FIG. 4.21 mostra um exemplo da propriedade transitiva hasAncestor (temAncestral). Se o
indivduo Matthew tem o ancestral Peter, e Peter tem o ancestral Willian, ento Mathew tem um ancestral
que Willian. Esse fato indicado pela linha tracejada na FIG. 4.21.
4.6.4)Propriedades simtricas
Se uma propriedade P simtrica, e relaciona um indivduo "a" ao indivduo "b", ento o indivduo "b"
tambm est relacionado ao indivduo "a" atravs da propriedade P. A FIG. 4.22 mostra um exemplo. Se o
indivduo Matthew est relacionado ao indivduo Gemma atravs da propriedade hasSibling (temIrmo),
ento Gemma tambm est relacionada a Matthew atravs da propriedade hasSibling. Em outras palavras,
se Matthew tem uma irm Gemma, ento Gemma tem um irmo que Matthew. Dito de outra forma, a
propriedade a prpria inversa.
24 of 83
Deseja-se tornar hasIngredient (temIngrediente) uma propriedade transitiva, de modo que, por exemplo, se
um recheio de pizza tem um ingrediente, ento uma pizza do mesmo recheio deve que ter o mesmo
ingrediente. Para definir as caractersticas da propriedade, utiliza-se o campo de Property Characteristics
(Caracterstica da Propriedade) conforme a FIG. 4.23, a qual est localizada no canto inferior direito da
etiqueta Property.
ATENO = se uma propriedade transitiva ela no pode ser funcional, uma vez que a
propriedade transitiva, por sua prpria natureza, pode formar cadeias de indivduos.
Deseja-se afirmar que uma Pizza pode ter apenas uma base. Existem vrias formas para fazer isso.
Escolhe-se tornar hasBase uma propriedade funcional, de modo que ela possa ter apenas um valor para um
determinado indivduo.
25 of 83
Figura 4.24: o domain (domain) e o range (escopo) para a propriedade hasTopping (temRecheio) e
suas propriedades inversas isToppingOf (RecheioDe). O domain para hasTopping Pizza e a range
para hasTopping PizzaTopping (RecheioDePizza). O domain e a range para isToppingOf so o
domain e a range para hasTopping.
ATENO = Domains (domnios) e Ranges (escopos) em OWL no so restries sujeitas a
verificao e so utilizados como axiomas em inferncias. Por exemplo, se a propriedade
hasTopping tem o conjunto domnio Pizza e aplica-se a propriedade hasTopping a IceCream
(indivduos membros da classe IceCream), o resultado pode ser um erro. possvel inferir que a
classe IceCream subclasse de Pizza (um erro gerado atravs do MI, apenas se Pizza for
disjunta de IceCream).
Deseja-se especificar que a propriedade hasTopping (temRecheio) tem um range (escopo) PizzaTopping
(RecheioDePizza). Para tal, usa-se a interface Range (Escopo). O menu suspenso do Protege assume
Instance (Instncia) como padro, indicando que a propriedade conecta instncias de classes a instncias de
classes.
26 of 83
27 of 83
"a hasTopping b": infere-se que "a" um membro da classe Pizza e que "b" um membro da
classe PizzaTopping.
Deseja-se preencher o domain (domnio) e o range (escopo) para o inverso da propriedade hasTopping
(temRecheio) e para isToppingOf (RecheioDe).
DICA = preciso garantir que o domnio e o escopo para as propriedades esto tambm
28 of 83
configurados para as propriedades inversas de maneira correta. Em geral, o domnio para uma
propriedade o escopo de seu inverso, e o escopo para uma propriedade o domnio de sua
inversa.
29 of 83
SIGNIFICADO = uma restrio descreve uma classe annima (no nomeada), a qual
composta de indivduos que satisfazem a restrio (vide o Apndice A para detalhes sobre
quantificao existencial e universal). Na realidade, quando restries so usadas para descrever
classes, elas especificam superclasses annimas da classe que est sendo descrita. Por exemplo,
pode-se dizer que MargheritaPizza uma subclasse de Pizza (dentre outras coisas), e tambm
uma subclasse das coisas que tem pelo menos um recheio que MozzarellaTopping.
30 of 83
Exerccio 16: Adicionar restrio a Pizza de forma que Pizza tenha uma
PizzaBase
1. Selecione Pizza na hierarquia de classes da etiqueta Classes.
2. Selecione NECESSARY na interface Asserted Conditions, de forma a criar uma condio necessria.
3. Pressione o boto Create restriction (Criar Restrio), mostrado na FIG. 4.29 Surge a caixa de dilogo
Create Restriction (vide FIG. 4.30), utilizada para criar uma restrio.
a lista de propriedades;
a lista de tipos de restrio;
a caixa de edio do filler;
o painel para construo de expresses.
Exerccio 17: Adicione restrio a Pizza especificando que Pizza deve ter uma
PizzaBase
31 of 83
(continuao do 16)
Figura 4.31: Painel Expression Builder (Construtor de Expresses) e boto Insert Class
4. Pressione o boto Ok para criar a restrio e feche a caixa dilogo. A restrio ser exibida na interface
Asserted Conditions. Caso algum erro seja detectados, a caixa de dilogo no fechada e uma mensagem
de erro exibida no painel para construo de expresses; nesse caso, verifique se a restrio, a propriedade
e o filler foram especificados corretamente.
A interface Asserted Conditions aparece agora de forma similar a apresentada na FIG. 4.33:
32 of 83
Figura 4.34: para que algo seja uma Pizza necessrio que tenha pelo menos uma PizzaBase; uma
Pizza uma subclasse de coisas que tem pelo menos um PizzaBase
33 of 83
34 of 83
35 of 83
Para a AmericanHotPizza a forma grfica Asserted Conditions (Condies Declaradas) deve agora parecer
como a imagem da FIG4.37:
36 of 83
descries das classes (condies) so utilizadas para determinar se existe dentre elas uma relao
superclasse/subclasse. Atravs de tais testes em todas as classes de uma ontologia possvel inferir
automaticamente a hierarquia de classes da ontologia. Outro servio padro oferecido pelo mecanismo de
inferncia o de consistency checking (verificao da consistncia). Baseado na descrio (condies) de
uma classe, o mecanismo de inferncia pode verificar se possvel, ou no, que uma classe possua
instncias. Uma classe considerada inconsistente se no possvel a ela ter instncias.
VOCABULRIO = MI-Mecanismos de inferncia (reasoners) so tambm chamados de
classificadores.
4.9.2)Uso do RACER
Para executar inferncias em ontologias no Protege-OWL preciso instalar um MI compatvel com o
DIG-Description Logic Implementers Group (Grupo de Desenvolvedores de Lgica Descritiva). Um
compatvel DIG possibilita comunicao via um protocolo padro para acesso ao MI. Antes disso, o MI
deve ser instalado, configurado e iniciado. Neste tutorial utiliza-se o RACER, disponvel na Internet em
uma variedade de plataformas. Depois de instalado, o RACER deve ser iniciado com a configurao padro
(o padro de comunicao o HTTP ativado na porta 8080). A FIG. 4.40 apresentar uma viso dos dados
exibidos na inicializao do RACER; a segunda linha de baixo para cima indica o estabelecimento da
comunicao HTTP, especifica o endereo IP e o nmero da porta. Caso deseje usar uma porta diferente,
preciso configurar o Protg-OWL atravs do comando Preferences... (Preferncias...) do menu OWL
(vide FIG.4.41)
37 of 83
Figura 4.43: O painel Inferred Hierarchy (Hierarquia Inferida), aberto ao lado do painel Asserted
Hierarchy (Hierarquia Declarada)
4.9.4)Classes inconsistentes
Para demonstrar o uso do MI na deteco de inconsistncias foi criada uma classe, subclasse de
CheeseTopping (RecheioDeQueijo) e de MeatTopping (RecheioDeCarne). Est estratgia normalmente
usada para verificar se a ontologia foi construda corretamente. As classes adicionadas para testar a
integridade da ontologia so conhecidas como ProbeClasses (Classes de Investigao).
38 of 83
como inconsistente quando a ontologia for classificada". Isso possibilita que outra pessoa, ao analisar a
ontologia, entenda que a classe foi deliberadamente criada como inconsistente.
4. Selecione a classe ProbeInconsistentTopping na hierarquia de classes, e escolha o NECESSARY no
campo Asserted Conditions (Condies Declaradas).
5. Clique no boto Add Named Class (Adicionar Classes Nomeadas) no campo Asserted Conditions
(Condies Declaradas). Ser exibido um dilogo com a hierarquia de classes, permitido que uma delas seja
selecionada. Selecione a classe VegetableTopping e pressione o boto Ok. A classe VegetableTopping ser
adicionada como uma condio necessria (como superclasse).
O campo Asserted Conditions deve estar parecido com FIG.4.44.
SIGNIFICADO = analise a situao: sabe-se que uma coisa no pode ser queijo e vegetal ao
mesmo tempo. Uma coisa no pode ser instncia de CheeseTopping (RecheioDeQueijo) e
instncia de VegetableTopping (RecheioDeVegetal) simultaneamente. Entretanto, o nome para
39 of 83
as classes escolhido pelo desenvolvedor. Para um MI, os nomes no tem significado, e ele no
pode determinar se alguma coisa inconsistente baseando-se em nomes. O motivo de a classe
ProbeInconsistentTopping ser detectada como inconsistente que suas superclasses
VegetableTopping e CheeseTopping so disjuntas. Assim, indivduos que so membros de
CheeseTopping no podem ser membros de VegetableTopping e vice-versa.
DICA = Para fechar a Inferred Hierarchy (Hierarquia Inferida) use o sinal X na parte superior
da janela da hierarquia inferida.
40 of 83
41 of 83
A atual descrio de CheesyPizza indica que se alguma coisa um CheesyPizza necessariamente uma
Pizza, e alm disso, ainda precisa ter pelo menos um recheio que um tipo de CheeseTopping. Para dizer
isto usam-se condies necessrias. Considere agora um indivduo qualquer. Sabe-se que esse indivduo
membro da classe Pizza; sabe-se tambm que tem pelo menos um tipo de CheeseTopping.
Entretanto, pela atual descrio de CheesyPizza essas informaes no so suficientes para determinar que
o indivduo membro da classe CheesyPizza. Para que isto seja possvel preciso mudar as condies de
CheesyPizza, de condies necessrias para condies necessrias e suficiente. As condies no vo ser
apenas necessrias para associao a classe CheesyPizza, elas vo ser tambm suficientes para determinar
que qualquer indivduo que as satisfaa um membro de CheesyPizza.
VOCABULRIO = uma classe que tem pelo menos um conjunto de condies necessrias e
suficientes conhecida como Defined Class (Classe Definida).
VOCABULRIO = classes que tem apenas condies necessrias so tambm conhecidas
como Partial Classes (Classes Parciais). Classes que tem pelo menos um conjunto de
condies necessrias e suficientes so tambm conhecidas como Complete Classes (Classes
Completas).
Para converter condies necessrias para condies necessrias e suficientes, movem-se as condies do
cabealho NECESSARY no campo Asserted Conditions (Condies Declaradas) para o cabealho
NECESSARY & SUFFICIENT. Isto pode ser feito arrastando e soltando as condies, uma a uma.
42 of 83
Condies
necessrias
Condies
necessrias e
suficientes
ATENO = Se por acidente Pizza foi descrita como NECESSARY & SUFFICIENT (ao invs
de E hasTopping CheeseTopping) no exerccio 29, o campo Asserted Conditions (Condies
Declaradas) vai aparecer como a imagem mostrada na FIG. 4.49. Neste caso, uma nova
condio necessria e suficiente foi criada, e no a desejada. Para corrigir este erro, arraste
Pizza sobre a restrio E hasTopping CheeseTopping.
Resumindo... se a classe A descrita por condies necessrias, ento pode-se dizer que se um indivduo
membro de A, ele deve satisfazer as condies. No se pode dizer que qualquer indivduo que satisfaa tais
condies um membro da classe A. Entretanto, se a classe A definida usando condies necessrias e
suficientes pode-se dizer que se um indivduo membro da classe A ele deve satisfazer as condies, e
pode-se dizer que qualquer indivduo satisfaz essas condies ento ele deve ser membro de A. As
condies no so apenas necessrias para a associao com A, mas tambm suficientes de forma a
determinar que, se alguma coisa satisfaz essas condies, um membro de A.
Como isso til na prtica? Suponha outra classe B, e que quaisquer indivduos que so membros da classe
B tambm satisfazem as condies que definem a classe A. Pode-se determinar que a classe B subclasse
de A. Verificar a relao classe/superclasse (subsumption relationship) de classes uma tarefa bsica de um
43 of 83
4.11)Classificao automtica
Um dos benefcios em construir uma ontologia com a sublinguagem OWL-DL a possibilidade computar
automaticamente a hierarquia de classes atravs de um MI. No caso de ontologias muito grandes (milhares
de classes), esse auxlio automtico para computar relacionamentos subclasse-superclasse vital. Sem um
MI muito difcil manter grandes ontologias em um estado logicamente correto. Em casos em que as
ontologias tem classes com muitas superclasses (herana mltipla) uma boa prtica construir uma
hierarquia de classes como uma rvore simples. Dessa forma, as classes na Asserted Hierarchy (Hierarquia
Declarada, aquela construda manualmente) no tm mais do que uma superclasse. Computar e manter
herana mltipla tambm trabalho do MI. Esta tcnica (as vezes chamada normalizao de ontologia)
ajuda a manter a ontologia em um estado sustentvel e modular. Isso promove a reutilizao da ontologia e
minimiza erros humanos inerentes na manuteno de hierarquias com herana mltipla.
Uma vez criada uma definio para CheesyPizza, pode-se usar o MI para computar automaticamente
subclasses de CheesyPizza.
44 of 83
Figura 4.51: vista do plug-in OWLViz apresentando a Asserted Hierarchy (Hierarquia Declarada)
para CheesyPizza
Fig.4.52: vista do plug-in OWLViz apresentando a Inferred Hierarchy (Hierarquia Inferida) para
CheesyPizza
ATENO = em geral, as classes no so classificadas como subclasses de Primitive Classes
(Classes Primitivas) pelo MI. As classes primitivas so aquelas que possuem apenas condies
necessrias. A exceo a esse fato ocorre quando uma propriedade tem um domnio que uma
classe primitiva. Isto pode fazer com que as classes sejam reclassificadas sob a classe primitiva
que o domnio da propriedade. No se recomenda o uso do domnio de propriedade para
causar tais efeitos.
4.11.1)Resultados da classificao
Depois de finalizada a classificao, as classes inconsistentes so exibidas em um painel conforme
45 of 83
apresentado na FIG. 4.53: o painel Classification Results (Resultados de Classificao) aberto na parte de
baixo da tela do Protege-OWL. O cone Spanner (uma pequena chave-inglesa) no lado esquerdo do painel
corresponde ao boto Assert Selected Changes (Aceitar Alteraes Selecionadas). Ao pressionar este
boto, os relacionamentos superclasse-subclasse inferidos pelo MI so transportados para a Asserted
Hierarchy (Hierarquia Declarada), a qual foi manualmente construda. Por exemplo, se o boto Assert
Selected Changes (Aceitar Alteraes Selecionadas) foi acionado com a seleo mostrada na FIG. 4.53,
CheesyPizza adicionado como superclasse de AmericanaPizza.
ATENO = Apesar da existncia desta facilidade, ela no considerada uma boa prtica para
inserir relacionamentos inferidos em hierarquias construdas manualmente ou na hierarquia
declarada enquanto a ontologia est sendo desenvolvida. Por isso aconselha-se evitar o uso
desse boto durante o desenvolvimento de uma ontologia.
4.12)Restries Universais
Todas as restries criadas at agora so restries existenciais (E). Esse tipo de restrio especifica a
existncia de pelo menos um relacionamento atravs de determinada propriedade com um indivduo
membro de uma classe, identificada pelo filler. Entretanto, a restrio existencial no obriga que os nicos
relacionamentos atravs da propriedade que possa existir sejam obrigatoriamente com indivduos membros
de uma classe especfica (filler).
Por exemplo, pode-se usar uma restrio existencial E hasTopping MozzarellaTopping para descrever os
indivduos que tem pelo menos um relacionamento atravs da propriedade hasTopping, com um indivduo
membro da classe MozzarellaTopping. Esta restrio no implica em que todos os relacionamentos
hasTopping devam ser, obrigatoriamente, membros da classe MozzarellaTopping. Para restringir um
relacionamento atravs de uma propriedade com indivduos membros de uma classe especifica, deve-se
usar a Universal Restriction (Restrio Universal).
As Universals Restictions (Restries Universais) so identificadas pelo smbolo A. Tais restries
condicionam o relacionamento atravs da propriedade com indivduos que so membros de uma classe
especfica. Por exemplo, a restrio universal expressa pela declarao A hasTopping MozzarellaTopping
descreve os indivduos cuja totalidade dos relacionamentos hasTopping ocorre com membros da classe
MozzarellaTopping. Os indivduos no tem relacionamentos hasTopping com indivduos que no so
membros de MozzarellaTopping.
VOCABULRIO = Universals Restictions (Restries Universais) so tambm conhecidas
como All Restrictions (Todas Restries).
ATENO = a Restrio Universal citada acima A hasTopping MozzarellaTopping, tambm
descreve os indivduos que no participam de nenhum relacionamento hasTopping. Um
indivduo que no participa de nenhum relacionamento hasTopping, por definio, nunca ter
um relacionamento hasTopping com indivduos que no so membros da classe
MozzarellaTopping, e a restrio assim satisfeita.
46 of 83
Figura 4.54: Expression Builder Panel (Painel Construtor de Expresses) para inserir UnionOf
(UnioDe)
7. Pressione o boto Ok para fechar o dilogo e criar a restrio. Caso exista algum erro o dilogo no
fechado e uma mensagem de erro aparece na parte de baixo do painel.
Neste ponto, o campo Asserted Conditions (Condies Declaradas) deve parecer como a FIG. 4.55.
47 of 83
DICA = Em vez de usar o boto Insert union (Inserir unio) no exerccio anterior, pode-se
simplesmente digitar OR (OU) na caixa de edio do filler, e a palavra automaticamente
convertida para o smbolo de unio ().
ATENO = em situaes como a do exemplo acima, um erro comum usar a interseo ao
invs da unio. Por exemplo, CheeseTopping VegetableTopping, lido como CheeseTopping
AND VegetableTopping. Embora CheeseTopping AND VegetableTopping seja uma frase
comum em linguagem natural, em termos lgicos significa que algo simultaneamente um tipo
de CheeseTopping e de VegetableTopping. Isto incorreto conforme demonstrado na seo
4.9.4. Se a classe CheeseTopping e VegetableTopping no so disjuntas, possvel dizer isso
com legitimidade lgica. Dessa forma, a classe no inconsistente e portanto no ser destacada
por um MI.
ATENO = no exemplo acima, uma opo criar duas restries universais, uma para
CheeseTopping (A hasTopping CheeseTopping) e outra para VegetableTopping (A hasTopping
VegetableTopping). Entretanto, quando restries mltiplas so utilizadas (para qualquer tipo
de restrio) a descrio total considerada como a interseo das restries individuais. Isso
equivalente a uma restrio com um filler que a interseo de MozzarellaTopping e
TomatoTopping. Conforme explicado, isto incorreto do ponto de vista lgico.
No momento, VegetarianPizza descrita usando condies necessrias. Entretanto, a descrio de
VegetarianPizza poderia ser considerada como completa. Sabe-se que qualquer indivduo que satisfaa a
essas condies deve ser um VegetarianPizza. Pode-se portanto, converter as condies necessrias de
VegetarianPizza em condies necessrias e suficientes. Isto vai permitir usar o MI para determinar a
subclasse de VegetarianPizza.
48 of 83
Figura 4.56: o campo Asserted Conditions e a definio de VegetarianPizza com Necessary and
Sufficient Conditions (Condies Necessrias e Suficientes)
SIGNIFICADO = converteu-se a descrio de VegetarianPizza em uma definio. Se alguma
coisa uma VegetarianPizza, ento necessrio que seja uma Pizza e tambm necessrio que
todos os recheios pertenam a classe CheeseTopping ou VegetableTopping. Alm disso, se
alguma coisa membro da classe Pizza e todos os recheios so membros da classe
CheeseTopping ou VegetableTopping, essas condies so suficientes para reconhecer que tal
coisa ser um membro da classe VegetarianPizza.
49 of 83
4.13.1)Axiomas de fechamento
Um Closure Axiom (Axioma de Fechamento) consiste em uma restrio universal que atua na propriedade
informando que ela pode apenas ser preenchida por fillers especficos. A restrio tem um filler que a
unio dos fillers que ocorrem nas restries existenciais da propriedade. Por exemplo, o Closure Axiom
(Axioma de Fechamento) da propriedade hasTopping para MargheritaPizza uma restrio universal que
atua na propriedade hasTopping, com um filler que a unio de MozzarellaTopping e de TomatoTopping,
ou seja, a declarao:
A hasTopping (MozzarellaTopping TomatoTopping).
Figura 4.57: campo Asserted Conditions (Condies Declaradas); MargheritaPizza com o axioma de
fechamento para a propriedade hasTopping
SIGNIFICADO = isto significa que um indivduo membro da classe MargeritaPizza deve ser
membro da classe Pizza, deve ter pelo menos um recheio que um tipo de MozzarellaTopping,
deve ter pelo menos um recheio que membro de TomatoTopping, e os recheios devem ser
apenas tipos de MozzarellaTopping ou TomatoTopping.
50 of 83
ATENO = um erro comum usar apenas restries universais nas descries. Por exemplo,
descreve-se MargheritaPizza como subclasse de Pizza, usando apenas a declarao A
hasTopping (MozzarellaTopping TomatoTopping) sem nenhuma restrio existencial.
Entretanto, pela semntica da restrio universal, a declarao significa realmente: coisas que
so Pizzas e somente tem recheios que so MozzarellaTopping ou TomatoTopping, OU, coisas
que so Pizzas e no tem qualquer recheio.
51 of 83
Tendo adicionado axiomas de fechamento na propriedade hasTopping para as Pizzas, usa-se agora o MI
para computar automaticamente a classificao.
4.14)Parties de Valor
Nessa seo criam-se Value Partitions (Parties de Valor), as quais so usadas para refinar as descries
de classes. Value Partitions (Parties de Valor) no so parte da linguagem OWL, ou de outra linguagem
de ontologia, so um padro de projeto.
Padres de projetos em ontologias so similares a padres de projeto em programao orientada a objetos:
so solues desenvolvidas por especialistas e reconhecidos como solues para problemas comuns de
modelagem. Conforme mencionado, as Value Partitions (Parties de Valor) podem ser criadas para refinar
descries de classe. Por exemplo, cria-se uma Value Partition chamada SpicinessValuePartition
(PartioDeValorApimentada) para descrever o spiciness ("o tanto de pimenta") de PizzaToppings
(RecheiosDePizza). As Value Partitions restringem a faixa de valores possveis para uma lista exaustiva,
por exemplo, a SpicinessValuePartition restringe a faixa para Mild (Levemente apimentado), Medium
(Mdio), e Hot (Muito Apimentado).
52 of 83
53 of 83
Analise as tarefas do assistente que reduzem o trabalho manual do usurio (FIG. 4.59 e 4.60):
1. Cria-se uma classe ValuePartition como subclasse de owl:Thing.
2. Cria-se uma classe SpicinessValuePartition como subclasse de ValuePartition.
3. Criam-se as classes Mild, Medium, Hot como subclasses de SpicinessValuePartition.
4. Aplica-se a disjuno as classes Mild, Medium e Hot.
5. Cria-se a classe unio de Mild, Medium e Hot como subclasse de SpicinessValuePartition.
6. Cria-se uma Object Property (propriedade de objeto) hasSpiciness.
7. A propriedade hasSpiciness se torna funcional.
8. Define-se SpicinessValuePartition como o escopo da propriedade hasSpiciness.
Figura 4.59: classes adicionadas pelo assistente Create ValuePartition (Criar Partio)
54 of 83
Figura 4.60: o campo Asserted Conditions (Condies Declaradas) mostrando a descrio da classe
SpicinessValuePartition
4.14.1)Axiomas de Cobertura
Como parte do padro ValuePartition usou-se um Covering Axiom (Axioma de Cobertura), o qual consiste
de duas partes: a classe que est sendo coberta, e as classes que formam a cobertura. Por exemplo, tem-se
trs classes A, B e C, e as classes B e C so subclasses de A. Tem-se um Covering Axiom (Axioma de
Cobertura) que especifica que a classe A coberta pela classe B e tambm pela classe C. Isto significa que
um membro da classe A deve ser membro da classe B e/ou C. Se as classes B e C so disjuntas, ento um
membro de A deve ser um membro de B ou de C. Em geral, embora B e C sejam subclasses de A, um
indivduo pode ser um membro de A sem ser membro de uma das classes B ou C.
No Protege-OWL um Covering Axiom (Axioma de Cobertura) manifesta-se como uma classe que a unio
das classes que esto sendo cobertas, as quais formam a superclasse da classe que est sendo coberta. No
caso de A, B e C, a classe A pode ter uma superclasse de B C. O efeito de um axioma de cobertura
representado na Fig. 4.61.
Figura 4.61: um esquema que mostra o efeito de usar um Covering Axiom para cobertura da classe A
com as classes B e C
A SpicinessValuePartition tem uma axioma de cobertura para indicar sua cobertura pelas classes Mild,
Medium e Hot, as quais so disjuntas para que um indivduo no possa ser um membro de mais de uma
delas. A classe SpicinessValuePartition tem uma superclasse que Mild Medium Hot. A cobertura
indica que um membro de SpicinessValuePartition deve ser membro de uma das classes: Mild ou Medium
ou Hot.
A diferena entre usar ou no um axioma de cobertura representada na Fig. 4.62. Em ambos os casos, as
classes Mild, Medium e Hot so disjuntas, elas no se sobrepe. No caso de no utilizao do axioma de
cobertura, um indivduo pode ser um membro da classe SpicinessValuePartition e no ser membro de Mild,
Medium ou Hot, uma vez que SpicynessValuePartition no coberta por Mild, Medium e Hot. Compare
com o caso em que a cobertura de axioma usada. Se um indivduo membro da classe
SpicinessValuePartition, ele deve ser membro de uma das trs subclasses Mild, Medium ou Hot, uma vez
que SpicinessValuePartition coberta por Mild, Medium e Hot.
55 of 83
56 of 83
Exerccio 41: criao de uma classe SpicyPizza como uma subclasse de Pizza
1. Criar uma subclasse de Pizza chamada SpicyPizza.
2. Selecione SpicyPizza na hierarquia de classes, escolha NECESSARY & SUFFICIENT em Asserted
Conditions (Condies Declaradas).
57 of 83
3. Pressione o boto Create restriction (Criar Restrio) no campo Asserted Conditions (Condies
Declaradas) para mostrar o dilogo.
4. Selecione E someValuesFrom como o tipo de restrio.
5. Selecione hasTopping como a propriedade a sofrer restrio.
6. O filler deve ser PizzaTopping E hasSpiciness Hot. Este filler descreve uma classe annima, a qual
contm os indivduos que so membros da classe PizzaTopping e tambm membros da classe de indivduos
relacionados aos membros da classe Hot atravs da propriedade hasSpiciness. Em outras palavras, diz
respeito as coisas que so PizzaToppings e tem um spiciness (tempero apimentado) que Hot. Para entrar
com esta restrio como um tipo de filler, digite no campo de edio de fillers a declarao:
PizzaTopping AND SOME hasSpiciness Hot.
A palavra AND convertida para o smbolo de interseo , a palavra SOME convertida para o smbolo
de quantificador existencial E.
7. O dilogo Create Restriction (Criar Restrio) deve agora estar similar a FIG. 4.67. Pressione Ok para
fechar o dilogo e criar a restrio.
Figura 4.67: Dilogo Create Restriction: uma restrio que descreve um SpicyTopping
8. Arraste Pizza de NECESSARY para a recm criada restrio:
(E hasTopping (PizzaTopping E hasSpiciness Hot)).
O campo Asserted Conditions (Condies Declaradas) deve estar agora similar a FIG.4.66.
58 of 83
4.16)Restries de Cardinalidade
Em OWL pode-se descrever a classe dos indivduos que tem pelo menos um, ou no mximo ou exatamente
um nmero especifico de relacionamentos com outros indivduos ou datatype values (valores de tipos de
dados). As restries que descrevem essas classes so conhecidas como Cardinality Restrictions
(Restries de Cardinalidade). Para uma dada propriedade P, uma Minimum Cardinality Restriction
(Restrio de Cardinalidade Mnima) especifica o nmero mnimo de relacionamentos P dois quais um
indivduo deve participar. Uma Restrio Cardinalidade Mxima (Maximum Cardinality Restriction)
especifica o nmero mximo de relacionamentos P dos quais um indivduo pode participar. Uma
Cardinality Restriction (Restrio de Cardinalidade) especifica o nmero exato de relacionamentos P dos
quais um indivduo participa.
Os relacionamentos (por exemplo, entre dois indivduos) so considerados como relacionamentos separados
quando se pode garantir que tambm so distintos os indivduos que funcionam como fillers dos
relacionamentos. Por exemplo, a FIG. 4.68 apresenta o indivduo Matthew relacionado ao indivduos Nick e
Hai, atravs da propriedade worksWith. O indivduo Matthew satisfaz uma restrio de cardinalidade
mnima 2 na propriedade worksWith, caso os indivduos Nick e Hai sejam indivduos distintos.
59 of 83
4. Pressione o boto Create restriction (Criar Restrio) para abrir o dilogo correspondente.
5. Selecione minCardinality como o tipo de restrio.
6. Selecione hasTopping como propriedade a sofrer a restrio.
7. Especifique uma Minimum Cardinality Restriction (Restrio de Cardinalidade Mnima) de 3, digitando
o nmero 3 na caixa de edio do filler.
8. Pressione Ok para fechar o dilogo e criar a restrio.
9. O campo Asserted Conditions (Condies Declaradas) deve estar com uma condio NECESSARY de
Pizza, e uma condio NECESSARY & SUFFICIENT de hasTopping 3. preciso que Pizza seja parte das
condies NECESSARY & SUFFICIENT. Arraste Pizza e solte sobre condio hasTopping 3.
O campo Asserted Conditions deve estar similar a imagem apresentada na FIG. 4.69.
60 of 83
61 of 83
complementOf e use o boto Insert class (Inserir Classe) para exibir o dilogo no qual pode-se selecionar
VegetarianPizza.
Figura 5.2: uso do Expression Builder Panel (Painel Construtor de Expresses) para inserir
Complement Of
5. Pressione enter para criar e atribuir a expresso.
Figura 5.4: campo Asserted Conditions (Condies Declaradas) mostrando um passo intermedirio na
criao da definio de NonVegetarianPizza.
No entanto, preciso adicionar Pizza as condies necessrias e suficientes, uma vez que no momento a
definio de NonVegetarianPizza diz que um indivduo que no um membro da classe VegetarianPizza
(qualquer outro indivduo) uma NonVegetarianPizza.
62 of 83
63 of 83
Fig. 5.6:
SIGNIFICADO = a UnclosedPizza no foi classificada como VegetarianPizza (em funo do
OWR). O MI no pode determinar se UnclosedPizza uma VegetarianPizza porque no existe
um axioma de fechamento em hasTopping, e a Pizza pode ter outros recheios. UnclosedPizza
poderia ser classificada como NonVegetarianPizza desde que no fosse classificada como
VegetarianPizza. No entanto, o OWR no demanda que UnclosedPizza, por no ser um
VegetarianPizza, seja uma VegetarianPizza: ela pode ser VegetarianPizza e pode no ser
VegetarianPizza. Dessa forma, UnclosedPizza no pode ser classificada como
NonVegetarianPizza.
64 of 83
65 of 83
O OWL no usa o UNA-Unique Name Assumption (vide seo 3.2.1). Por isso, os indivduos podem ser
declarados como SameAs (IgualA) ou DierentFrom (DiferenteDe) de outros indivduos (FIG. 6.3). Tendo
criado alguns indivduos pode-se us-los em descries de classes.
66 of 83
O campo Asserted Conditions (Condies Declaradas) deve agora estar similar a Fig. 6.4.
Figura 6.4: o campo Asserted Conditions mostrando restrio hasValue para MozzarellaTopping
SIGNIFICADO = as condies definidas para MozzarellaTopping informam que: indivduos
membros da classe MozzarellaTopping so tambm membros da classe CheeseTopping e esto
relacionados ao indivduo Italy atravs da propriedade hasCountryOfOrigin; esto relacionadas
a pelo menos um membro da classe Mild atravs da propriedade hasSpyciness. Em linguagem
natural, pode-se dizer que coisas que so tipos de MozzarellaTopping (RecheioDeMussarela)
so tambm CheeseTopping (RecheioDe Queijo), vem da Italy e tem Mild Spyciness
("mediamente" apimentados).
6.3)Classes enumeradas
O OWL permite que classes sejam definidas listando-se os indivduos que so seus membros. Por exemplo,
pode-se definir uma classe DaysOfTheWeek (DiasDaSemana) como a classe que contm os indivduos (e
somente os indivduos): Sunday (Domingo), Monday (Segunda), Tuesday (Tera), Wednesday (Quarta),
Thursday (Quinta), Friday (Sexta) e Saturday (Sbado). Classes definidas dessa forma so conhecidas
como Enumerated Classes (Classes Enumeradas).
No Protege-OWL as classes enumeradas so definidas usando-se o editor de expresses no campo Asserted
Conditions (Condies Declaradas). Os indivduos que compem a classe enumerada so listados,
separados por espaos e dentro de colchetes, por exemplo: {Sunday Monday Tuesday Wednesday Thursday
Friday Saturday}. Os indivduos j devem ter sido criados na ontologia (etiqueta Individuals). As classes
enumeradas descritas dessa forma so classes annimas: so as classes dos indivduos, e apenas dos
indivduos, listados na enumerao. Pode-se anexar esses indivduos a uma Named Class (Classe Nomeada)
criando a enumerao como uma condio NECESSARY & SUFFICIENT.
67 of 83
Figura 6.6: esquema da classe Country como equivalente a uma Enumerated Class
O filler para as propriedades de anotao deve ter um dado literal, uma URI de referncia ou um
indivduo. Um dado literal um caractere de representao de um datatype value (valor de tipo de
dados), por exemplo, Matthew, "25", "3.11".
As propriedades de anotao no podem ser usadas em axiomas que atuam sobre propriedades. Por
exemplo, no podem ser usados na hierarquia de propriedades, de forma que no podem ter
subpropriedades, ou ser subpropriedade de outra propriedade. Tambm no podem ter Domain
(Domnio) e Range (Escopo) especifico.
O OWL tem cinco propriedades de anotao pr-definidas que podem ser usadas para fazer comentrios em
classes (inclusive classes annimas, tais como restries), propriedades e indivduos:
1. owl:versionInfo: em geral, o range (escopo) dessa propriedade um string.
2.
rdfs:label: o range (escopo) um string. Esta propriedade usada para adicionar nomes
significativos (para pessoas) aos elementos da ontologia, tais como classes, propriedades e
indivduos. O rdfs:label tambm ser usado para fornecer nomes multilnges para elementos de
ontologia.
68 of 83
rdfs:isDefinedBy: o range (escopo) uma URI usada para referenciar uma ontologia que define
elementos da ontologia tais como classes, propriedades e indivduos.
Por exemplo, a propriedade de anotao rdfs:comment usada para guardar comentrios sobre as classes
dos plug-ins do Protege-OWL. A propriedade de anotao rdfs:label pode ser usada para fornecer nomes
alternativos para classes, propriedades, etc.
Existem tambm propriedades de anotao que podem ser usadas para comentar uma ontologia. A
propriedades de anotao de ontologias (listadas abaixo) tem como range (escopo) uma URI, usada para
referncia a outra ontologia. tambm possvel usar a propriedade de anotao owl:VersionInfo para
comentrios de ontologia.
owl:incompatibleWith: identifica a verso anterior de uma ontologia que no compatvel com a atual.
Para criar propriedades de anotao, usam-se os botes Create annotation datatype property (Criar
anotao de propriedade de tipo de dados) e Create annotation object property (Criar anotao de
propriedade de objetos), localizados na etiqueta Properties (Propriedades). Para usar as propriedades de
anotao, acessa-se a interface de anotaes, conforme apresentado na FIG.6.7.
A interface de anotao est disponvel em todas as etiquetas (OWL-Classes, Properties, Individuals e
Metadata) possibilitando anotaes em classes, propriedades, indivduos e ontologias, respectivamente.
Uma anotao pode tambm ser adicionada a restries e a outras classes annimas clicando com o boto
direito no campo Asserted Conditions (Condies Declaradas) e selecionando Edit annotation properties...
(Editar propriedades da anotao...).
69 of 83
condies do conjunto selecionada e ento a nova condio criada, ou uma condio existente
arrastada sobre o conjunto existente (sobre o cabealho NECESSARY & SUFFICIENT).
70 of 83
7.Outros tpicos
7.1)Perfil da linguagem
Conforme mencionado anteriormente, existem trs sub-linguagens OWL: OWL-Lite, OWL-DL e OWL-Full.
Ao editar uma ontologia, o Protege-OWL tem capacidade de restringir os constructos usados, de forma que
a ontologia possa ser classificada em uma das sub-linguagens, OWL-DL ou OWL-Full. A sub-linguagem
desejada, ou perfil da linguagem a ser utilizada definida atravs do comando Preferences (Preferncias)
do Protege-OWL. A escolha entre OWL-DL e OWL-Full feita pelo comando Supports One of the
Following OWL Species (Suporte a Uma das Seguintes Espcies OWL), e selecionada dentre uma das duas
opes disponveis: OWL DL (Optimized for reasoning) (otimizado para inferncias), ou o OWL Full
(supports the complete range of OWL elements) (suporta todos os elementos OWL).
http://a.com/ontology#PizzaTopping.
O
nome
completo
da
classe
MargheritaPizza
71 of 83
nome
completo
para
a
classe
Wing
na
ontologia
de
pssaros
72 of 83
Usa-se a interface Namespace Prefixes (FIG. 7.1) para criar ou para configurar namespaces e prefixos
associados no Protege-OWL. A interface contm trs colunas: Prefix, Namespace e Imported (a coluna
Imported ser tratada mais adiante).
N do T: Na verso 3.4 (Build 130) do Protege, conforme pode-se notar na FIG. 7.1, a
interface ligeiramente diferente apresentando apenas duas colunas, a saber Prefix e
Namespace.
Vai-se adicionar prefixo e namespace para uma ontologia de vinho que tem o namespace
http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#. A ontologia de vinhos um exemplo
didtico utilizado no guia W3C-OWL que contm dados sobre tipos de vinhos e vincolas.
namespace
prefixado
vin
ser
73 of 83
namespaces, e importar totalmente a ontologia. Quando uma ontologia importa outra, no feita uma
simples referencia as classes, as propriedades e aos indivduos: os axiomas e fatos contidos na ontologia
importada so includos na ontologia destino. Observe que o OWL permite importar ontologias de maneira
cclica como, por exemplo, OntologyA importa OntologyB, e OntologyB importa OntologyA.
Locais Alternativos
Quando se pretende tornar uma ontologia disponvel para importao, uma boa prtica definir a URI do
namespace como uma URL que aponta para o lugar onde est a ontologia. Na maioria das vezes trata-se de
um endereo web. Assinalando a caixa de seleo Imported (Importada), o Protege-OWL tenta achar a
ontologia no local especificado pela URI do namespace. Mas e se no existe conexo a Internet, ou a
ontologia no existe naquela URI? Nesse caso, possvel especificar uma URI/URL alternativa, a qual
aponta para uma cpia local da ontologia. Por exemplo, uma URL que aponta para um local no disco
74 of 83
rgido, ou para o servidor rede local, etc. Locais alternativos so especificadas no arquivo de Ontology
Polices (Polticas da ontologia), localizado na pasta do plug-in do Protege-OWL. Este arquivo no precisa
ser editado manualmente, pode ser editado com o dilogo de poltica da ontologia.
Para especificar um local alternativo para uma ontologia importada, siga esses passos.
creator (criador, autor): uma pessoa, uma organizao, ou um servio; em geral o nome do creator
usado para indicar uma entidade.
subject (assunto): expresso por palavras chaves, frases ou cdigos de classificao que descrevem um
tpico da pesquisa; a prtica recomenda selecionar um termo a partir de um vocabulrio controlado
ou esquema de classificao.
description (descrio): inclui resumos, tabela de assuntos, referncia para uma representao grfica
de assuntos ou texto livre sobre o assunto, dentre outras;
75 of 83
Figura EXTRA 10: Create Ontology Repository (Criar repositrio para ontologia)
3. Uma mensagem solicita que a ontologia seja recarregada. Pressione Yes.
4. A DC Ontology importada. Feche o dilogo DC metadata com o boto Close.
5. Alterne para a etiqueta Properties. Conforme apresentado na FIG. 7.3, verifique que vrias propriedades
de anotao (do Dublin Core Metadata Terms) foram importadas. Essas propriedades podem ser usadas no
normalmente.
76 of 83
77 of 83
Em alguns casos, o Protege-OWL capaz de modificar ou corrigir aspectos da ontologia em que um teste
detectou defeitos. Quando o teste selecionado, fica disponvel um pequeno boto de ferramentas
denominado spanner (smbolo de uma chave inglesa), do lado esquerdo do painel do resultados. Clicando
neste boto, possvel reparar o defeito na ontologia detectado pelo teste.
78 of 83
Apndice A
Tipos de restries
Esse apndice contm informaes adicionais sobre os tipos de restries para propriedades OWL.
indicado para leitores no familiarizados com noes de lgica.
Todos os tipos de restries descrevem um conjunto sem nome que pode conter indivduos. Esse conjunto
corresponde a uma classe annima. Quaisquer indivduos membros dessa classe annima satisfazem a
restrio que descreve a classe (FIG. A.1). O termo "restries" descreve restries sobre relaes atravs
de propriedades, das quais participam indivduos.
Quando se descreve uma classe nomeada usando restries, o que se faz realmente na prtica descrever
uma superclasse annima da classe nomeada.
79 of 83
80 of 83
Essa combinao descreve o conjunto de indivduos que tem pelo menos um relacionamento hasTopping
com um indivduo da classe MozzarellaTopping, e apenas tem relacionamentos hasTopping com indivduos
da classe MozzarellaTopping.
No comum, e em geral significa um erro, ao descrever uma classe, que se use a restrio universal junto a
propriedade, sem uso da restrio universal correspondente junto mesma propriedade. No exemplo acima,
caso se use apenas a restrio universal A hasTopping Mozzarella, ento se pode ter descrito o conjunto de
indivduos que apenas participa na relao hasTopping com membros da classe Mozzarella, e tambm
aqueles indivduos que no participam em qualquer relacionamento hasTopping (provavelmente, um erro).
Figura A.4: restrio hasValue prop abc, onde as linhas pontilhadas indicam que esse tipo de
restrio no restringe a propriedade usada na restrio, a indivduos usados exclusivamente na
restrio hasValue.
81 of 83
ou igual a (). Por exemplo, a cardinalidade mnima hasTopping 3 descreve os indivduos (uma classe de
annimos que contm indivduos) que participam em pelo menos trs relacionamentos hasTopping. As
restries de cardinalidade mnima no estabelecem limites mximos relativos ao nmero de
relacionamentos que um indivduo pode participar, em uma propriedade.
82 of 83
Apndice B
Uma classe OWL especificada em termos de suas superclasses. Tais superclasses so em geral classes
nomeadas e restries, sendo que as restries so de fato classes annimas. As superclasses tambm
podem tomar a forma de "descries complexas" construdas a partir de descries simples, conectadas por
operadores lgicos. Os operadores mais conhecidos so:
AND (): a classe formada com o operador AND e conhecida como classe interseo; a classe
83 of 83
A classe annima descrita pode ser usada em outra descrio de classe. Por exemplo, a classe person pode
ser equivalente a unio de man e woman.