Linguagem de Composi¸c˜ ao de Servi¸cos - 3 O M´ etodo de Certifica¸ c˜ ao de

3 O M´ etodo de Certifica¸ c˜ ao de

3.1.3 Linguagem de Composi¸c˜ ao de Servi¸cos

Composi¸cões de servi¸cos descrevem o fluxo de trabalho (workflow) de aplica¸cões que combinam chamadas de servi¸cos web. A linguagem empregada nesta tese para expressar composi¸cões de servi¸cos é descrita a seguir. A linguagem contempla os construtores co- muns encontrados em linguagens de orquestra¸cão de servi¸cos, tal como BPEL (Business Process Execution Language) [9]. Através da gramática empregada nesta tese, busca-se simplificar a apresenta¸cão e manipula¸cão dos construtores usados na defini¸cão dos workflows, facilitando assim sua legibilidade e manipula¸cão.

3.1.3.1 Sintaxe

A linguagem de composi¸cão de servi¸cos web semânticos pode ser dividida em duas partes: i) uma primeira contendo as se¸cões de declara¸cões e, ii) a segunda contendo a defini¸cão do workflow.

A gramática empregada para definir as se¸cões de declara¸cões da linguagem é ilus- trada na Figura 2. O s´ımbolo não-terminal semanticPEWS define a estrutura de uma composi¸cão de servi¸cos. Uma composi¸cão de servi¸cos é composta pelos conjuntos de declara¸cões de ontologias (OntologyDecl* ), de conceitos (ConceptDecl* ), de proprieda- des (PropertyDecl* ), de indiv´ıduos (IndividualDecl* ), de variáveis (VariableDecl* ) e de servi¸cos (ServiceDecl* ), além de uma especifica¸cão (SpecificationDecl ).

O s´ımbolo não-terminal OntologyDecl permite a declara¸cão de ontologias de dom´ınio cujas terminologias são necessárias para a defini¸cão da composi¸cão de servi¸cos. Cada ontologia é identificada por um prefixo e por uma URL.

O s´ımbolo não-terminal ConceptDecl permite declarar os conceitos ontológios (defi- nidos pelas ontologias de dom´ınio) que são empregados na descri¸cão dos elementos da composi¸cão de servi¸cos. A declara¸cão de cada conceito está relacionada ao prefixo de uma ontologia de dom´ınio.

O s´ımbolo não-terminal PropertyDecl permite declarar as propriedades usadas na defini¸cão dos elementos da composi¸cão. Da mesma forma que os conceitos, as propriedades estão relacionadas a uma ontologia de dom´ınio através da identifica¸cão de seu prefixo na declara¸cão da propriedade.

O s´ımbolo não-terminal IndividualDecl permite declarar que indiv´ıduos nomeados definidos nas ontologias de dom´ınio possam ser referenciados na defini¸cão dos elementos da composi¸cão de servi¸cos.

O s´ımbolo não-terminal VariableDecl permite definir identificadores para representar indiv´ıduos usados na defini¸cão dos elementos da composi¸cão. Cada s´ımbolo não-terminal é associado a um conceito dado por uma ontologia do dom´ınio.

O s´ımbolo não-terminal ServiceDecl permite declarar os servi¸cos web semânticos uti- lizados na defini¸cão do workflow. Cada servi¸co identificado nesta se¸cão está associado à defini¸cão de seus elementos conforme dado pela defini¸cão 3.1.1.

O s´ımbolo não-terminal SpecificationDecl define uma especifica¸cão de corre¸cão parcial, composta pelos s´ımbolos não-terminais Pre, W e Post.

O s´ımbolo não-terminal Pre denota a pré-condi¸cão da especifica¸cão, sendo composta por uma lista de axiomas de ABox (s´ımbolo não-terminal AxiomList). Por outro lado, o s´ımbolo não-terminal Post denota uma lista de axiomas de ABox expressando a pós- condi¸cão da especifica¸cão.

O s´ımbolo não-terminal AxiomList denota uma lista de axiomas de ABox, onde cada s´ımbolo não-terminal Axiom denota um axioma de ABox. O s´ımbolo não-terminal Axiom denota uma asser¸cão de conceito ou de propriedade, representada na gramática pelo s´ımbolo θ. No contexto desta tese, os axiomas de ABox são definidos de acordo com o fragmento ALC da lógica descritiva, conforme descrito na secão 2.1.1.1.

O s´ımbolo n˜ao-terminal W denota o workflow, sendo definida conforme a gram´atica dada na Figura 3.

SemanticPEWS ::= OntologyDecl∗ ConceptDecl∗ PropertyDecl∗ IndividualDecl∗ VariableDecl∗ ServiceDecl∗

SpecificationDecl (3.1)

OntologyDecl ::= ontology Ident=Url (3.2)

ConceptDecl ::= concept Ident=Ident:Ident (3.3)

PropertyDecl ::= property Ident=Ident:Ident (3.4)

IndividualDecl ::= individual Ident=Ident:Ident (3.5)

VariableDecl ::= variable Ident ofType Ident (3.6)

ServiceDecl ::= service Ident=Url (3.7)

SpecificationDecl ::= Pre W Post (3.8)

Pre ::= @pre[AxiomList] (3.9)

Post ::= @post[AxiomList] (3.10)

AxiomList ::= Axiom{, Axiom} (3.11)

Axiom ::= θ (3.12)

Url ::= Ident (3.13)

Ident ::= Letter | Digit | SpecialChar (3.14) Figura 2: Gramática das se¸cões de declara¸cão da linguagem de composi¸cão. A linguagem de workflow é apresentada na Figura 3. Como pode ser observado a partir da gramática, um workflow é denotado por W .

O s´ımbolo terminal S representa uma invoca¸cão de servi¸co semântico associado a duas tuplas de parâmetros, uma de entrada representada por I e outra de sa´ıda representada por O. A invoca¸cão de servi¸co constitue o elemento básico na defini¸cão de workflows. Sua semântica intuitiva visa abstrair a funcionalidade espec´ıfica requerida naquele ponto

do workflow onde a invocacão aparece. Em outras palavras, a defini¸cão do workflow baseia-se em um conjunto de funcionalidades abstra´ıdas pelas invoca¸cões dos servi¸cos semânticos. Cada invoca¸cão de servi¸co semântico corresponde a uma opera¸cão em um servi¸co concreto (ou seja, para cada servi¸co semântico, considera-se apenas sua descri¸cão funcional - hI, O, P re, Ei, não seu modelo de processo - descri¸cão comportamental). Cada opera¸cão do servi¸co semântico está equipada com uma pré-condi¸cão e uma pós-condi¸cão expressando assim sua semântica funcional. As condi¸cões dizem respeito às suposi¸cões requeridas (pré-condi¸cões) sobre o estado do mundo para que a execu¸cão do servi¸co ocorra assim como os efeitos desejados (pós-condi¸cões) no estado do mundo após sua execu¸cão.

O construtor sequencial, representado pelo s´ımbolo “;”, expressa a composi¸cão sequen- cial. Na expressão W1; W2, o workflow W2 inicia sua execu¸cão somente após o término da

execu¸c˜ao do workflow W1.

O construtor paralelo, representado pelo s´ımbolo “k”, expressa a composi¸cão paralela de workflows. Os workflows W1 e W2iniciam suas execu¸cões de forma independente. Após

o término da execu¸cão de todos os workflows paralelos, o fluxo de execu¸cão continua com a execu¸cão do próximo workflow.

O construtor condicional, representado por “if A then W1 else W2”, expressa a

composi¸cão condicional de workflows. A semântica intuitiva é semelhante à de outras linguagens, onde a execu¸cão do workflow W1 depende da avalia¸cão positiva da condi¸cão

A, enquanto que a execu¸c˜ao do workflow W2 depende da falsidade da condi¸c˜ao A.

A linguagem de asser¸cões usada para expressar as condi¸cões dos construtores (como por exemplo, a asser¸cão A no construtor condicional) usa uma forma simplificada das fórmulas da lógica descritiva. Na linha 3.21 na Figura 3, o s´ımbolo θ representa asser¸cões de conceitos e de propriedades, denotados por C(a) e r(a, b), onde C representa um conceito arbitrário expresso no fragmento ALC, r representa uma propriedade primitiva, “a” e “b” representam indiv´ıduos do dom´ınio.

Outro construtor condicional permitido na linguagem de workflow ´e a escolha guar-

dada, representada por “[A1]W1 + [A2]W2”. Neste caso, a execu¸c˜ao dos workflows W1 e

W2 dependem da avalia¸c˜ao positiva de suas respectivas condi¸c˜oes associadas A1 e A2. No

caso de ambas as condi¸cões serem verdadeiras, é realizada uma escolha não-determin´ıstica para decidir qual workflow será executado. No caso de ambas as condi¸cões serem falsas, nenhum dos workflows é executado e o estado resultante permanece inalterado.

execu¸cão iterativa do workflow W até que a condi¸cão A seja avaliada como falso. W ::= S(I, O) (3.15) | W1 ; W2 (3.16) | W1 k W2 (3.17) | if A1 then W1 else W2 (3.18) | while A1 do W1 (3.19) | [A1]W1+ [A2]W2 (3.20) A ::= ⊤ | ⊥ | θ (3.21)

Figura 3: Construtores de Workflow e de Asser¸c˜oes

3.1.3.2 Semˆantica

A semântica formal da linguagem de workflow é definida através da semântica ope-

racional estruturada (big-step) [99]. A semˆantica operacional da linguagem ´e descrita a

seguir.

Um estado é dado pelo conjunto de asser¸cões (de conceitos e de propriedades) contidas no componente ABox de uma base de conhecimento expressa no fragmento ALC da lógica descritiva.

A validade de uma asser¸cão θ, relativa a uma base de conhecimento hT , Ai, pode ser expressa como uma rela¸cão hT , Ai |= θ, onde T e A representam o componente terminológico e o componente assertivo de uma base de conhecimento, respectivamente. A rela¸cão de satisfa¸cão acima pode ser descrita como “θ é válida na base de conhecimento hT , Ai” ou, de outra forma, “a base de conhecimento hT , Ai satisfaz a asser¸cão θ”.

A interpreta¸cão de asser¸cões é dada pela funcão de avalia¸cão [[A]] : (T × A) → {T rue, F alse} e definida como a seguir:

[[⊤]](t, a) = T rue [[⊥]](t, a) = F alse

[[θ]](t, a) = ht, ai |= θ

A semântica dos construtores da linguagem de workflow descreve uma transi¸cão de uma configura¸cão dada pelo par hW, ht, aii para um novo estado ht, a′_{i. A transi¸cão para}

(servico) ht, a′i = update(ht, ai, ELi)

(S(I, O), ht, ai) ht, a′_i

[[P re]](t, a) = True∧ [[ECi]](t, a) = True (seq) (W1, ht, ai) ht, a′i (W2, ht, a′i) ht, a′′i (W1; W2, ht, ai) ht, a′′i (par) (W1, ht, ai) ht, a′i (W2, ht, a′i) ht, a′′i (W 1 k W2, ht, ai) ht, a′∧ a′′i (if ) (W1, ht, ai) ht, a′i

(if A then W1elseW2, ht, ai) ht, a′i

[[A]](t, a) = True

(if₁) (W2, ht, ai) ht, a′i

(if A then W1elseW2, ht, ai) ht, a′i

[[¬A]](t, a) = True

(escolha) (W1, ht, ai) ht, a′i

([A1]W1+ [A2]W2, ht, ai) ht, a′i [[A

1]](t, a) = True (escolha1) (W2, ht, ai) ht, a′i ([A1]W1+ [A2]W2, ht, ai) ht, a′i [[A2]](t, a) = True (escolha2) ([A1]W1+ [A2]W2, ht, ai) ht, ai [[¬(A1∨ A2)]](t, a) = True

(while) (W1, ht, ai) ht, a′i (while A1doW1, ht, a′i) ht, a′′i (while A1doW1, ht, ai) ht, a′′i

[[A1]](t, a) = True

(while1)

(while A1doW1, ht, ai) ht, ai

[[¬A1]](t, a) = True

Figura 4: Semˆantica Natural da Linguagem de Workflow. ilustrado na Figura 4.

A semântica de uma invoca¸cão de servi¸co é ilustrada pela regra (servi¸co) na Figura 4. A regra expressa que uma nova base de conhecimento ht, a′_{i é obtida como resultado da}

invocacão de um servi¸co web semântico. A nova base de conhecimento ht, a′_{i é obtida}

como resultado da aplica¸cão da opera¸cão de atualiza¸cão update na base de dados inicial juntamente com o efeito ELi do servi¸co invocado. A asser¸cão ELi denota o literal Li

associado ao i-´esimo efeito condicional Ci/Li do servi¸co invocado S. Entretanto, para que

ocorra a transi¸cão para a nova base de conhecimento ht, a′_{i, é necessário que as condi¸cões}

especificadas na regra sejam satisfeitas. As condi¸cões requerem que a pré-condi¸cão P re do servi¸co invocado S seja satisfeita no estado inicial (i.e., ht, ai), assim como o requisito de que uma das condi¸cões dadas nos efeitos condicionais Ci do servi¸co S (i.e., ECi) seja

tamb´em satisfeita pela base de conhecimento inicial. A necessidade do uso da opera¸c˜ao

update para a atualiza¸cão da base de conhecimento é discutida na se¸cão 2.1.1.2. Na

se¸cão 3.1.2 é apresentada a defini¸cão formal da opera¸cão update (listing 3.1).

A semântica operacional do construtor de composi¸cão sequencial descreve que a execu¸cão sequencial de dois workflows W1 e W2 produz um ABox a′′ como resultado,

sendo que a configura¸c˜ao usada para a transi¸c˜ao do workflow W2 contempla o ABox

intermediário a′ _{produzido como resultado da transi¸cão da configura¸cão de W} 1.

A semântica do construtor de composi¸cão paralela descreve que o ABox resultante da execu¸cão dos workflows paralelos W1 e W2 é dada pela conjun¸cão dos ABoxes produzidos

por cada transi¸c˜ao separadamente, i.e., a′_{∧ a}′′_{. Esta regra assume que os workflows W} 1 e

W2 são independentes, caso contrário, a conjun¸cão dos ABoxes resultantes poderia gerar

um base de conhecimento inconsistente.

A semˆantica do construtor condicional if (dada pelas regras if e if1) expressa que um

novo ABox a′ _{´e obtido como resultado da execu¸c˜ao do workflow W}

1 ou W2, dependendo

do resultado da avaliac˜ao da condi¸c˜ao A.

A semˆantica do construtor de escolha guardada ´e expressa pelas regras escolha, escolha1

e escolha2 na Figura 4. Como pode ser observado nas regras escolha e escolha1, o constru-

tor escolha guardada é não-determin´ıstico uma vez que ambas as condi¸cões A1e A2podem

ser avaliadas como verdadeiras. Neste caso, a sele¸cão não-determin´ıstica do workflow a ser executado será decidida pelo mecanismo de execu¸cão de workflow. Independente do workflow escolhido para execu¸cão, um novo ABox a′ _{será produzido como resultado. A}

regra escolha2 expressa a situa¸cão em que ambas as condi¸cões A1 e A2 são avaliadas como

falsas, garantindo assim que o ABox resultante é idêntico àquele da configura¸cão inicial, ou seja, não há atualiza¸cão de estado.

Por fim, as regras while e while1 expressam a semˆantica operacional do construtor

iterativo da linguagem de workflow. A regra while1 expressa a situa¸c˜ao em que a condi¸c˜ao

é avaliada para falso e o ABox dado na configura¸cão inicial é mantido inalterado. Por outro lado, a regra while expressa a semântica no caso em que a condi¸cão é verdadeira e a itera¸cão é executada.

3.2 M´etodo de Certifica¸c˜ao

O objeto de estudo desta tese está relacionado com a verifica¸cão formal de composi¸cões de servi¸cos web semânticos. A verifica¸cão formal diz respeito à busca de uma prova de que uma composi¸cão de servi¸cos web semânticos cumpre uma especifica¸cão dada na forma de pré- e pós-condi¸cões. O método de certifica¸cão descrito nesta se¸cão objetiva prover os meios necessários para derivar a prova de que a composi¸cão de servi¸cos web semânticos cumpre uma dada especifica¸cão.

As composi¸cões de servi¸cos web semânticos são formalizadas através da gramática descrita na se¸cão 3.1.3. Os servi¸cos web semânticos invocados nas composi¸cões (workflows) são definidos de acordo com a estrutura descrita na defini¸cão 3.1.2.

O método de certifica¸cão foi estruturado em duas dimensões, denominadas de base e

funcional.

A dimensão base tem como objetivo verificar que as invoca¸cões dos servi¸cos web semânticos contidas no workflow (os elementos base) estão em conformidade com a de-

fini¸cão dos servi¸cos web semânticos. A similaridade semântica entre os conceitos on-

tológicos usados para descrever os parâmetros formais dos servi¸cos é usada para certificar que a invocacão dos servi¸cos está em conformidade com suas defini¸cões.

A dimensão funcional tem como objetivo verificar que o workflow cumpre uma dada especifica¸cão. Esta dimensão emprega uma abordagem axiomática baseada na lógica de Hoare [54] para certificar que o workflow verifica a sua especifica¸cão.

As se¸cões a seguir apresentam a formaliza¸cão do método de certifica¸cão. A descri¸cão formal do método de certifica¸cão proposto é acompanhada por sua aplica¸cão em um exemplo objetivando exemplificar e destacar os aspectos práticos do método de certifica¸cão.

3.2.1 Running Example

Esta se¸cão descreve o running example usado para exemplificar a aplica¸cão do método de certifica¸cão proposto neste trabalho. O running example foi adaptado e estendido do exemplo Congo Service apresentado em [100], o qual está inserido no contexto de comércio eletrônico. Seu propósito é permitir (iterativamente) a escolha de diversos produtos através do fornecimento de suas especifica¸cões, a realiza¸cão do pagamento com cartão de crédito e o agendamento da entrega dos produtos. A funcionalidade do workflow está definida através da orquestra¸cão de diversos servi¸cos web semânticos, conforme ilustrado na Figura 5.

A lógica do workflow, ilustrado na Figura 5, é descrita pela composi¸cão paralela de dois (sub-) workflows W1 (linhas 1 a 8) e W2(linhas 10 a 29), os quais são compostos

sequencialmente com o (sub-) workflow W3 (linha 31). Em uma perspectiva macro, o

workflow pode ser expresso pela composi¸c˜ao dos respectivos (sub-) workflows da seguinte forma:

O workflow W1 expressa a funcionalidade de autentica¸c˜ao do usu´ario requerida pela

aplica¸cão de comércio eletrônico. A funcionalidade é implementada através da verifica¸cão se o usuário está ou não cadastrado na aplica¸cão de comércio eletrônico. Caso não esteja cadastrado, o workflow W1 procederá com o cadastramento do usuário. Após o cadas-

tramento, o usuário será autenticado através da cria¸cão de uma sessão, permitindo então que as informa¸cões do perfil do usuário sejam obtidas.

O workflow W2 permite ao usu´ario selecionar (iterativamente) os produtos desejados.

Para isto, o workflow solicita ao usuário, através da invoca¸cão do servi¸co getProductS-

pecification, a especifica¸c˜ao do produto desejado. A partir da especifica¸c˜ao informada

pelo usuário, o workflow procede com a verifica¸cão da disponibilidade do produto em estoque através da invoca¸cão do servi¸co search. Caso haja disponibilidade do produto em estoque, este será adicionado ao carrinho de compras do usuário e a especifica¸cão de um novo produto será solicitada ao usuário. A cada inclusão de um produto no carrinho, obtêm-se como resultado o valor total dos produtos contidos no carrinho. Após o término da escolha dos produtos, o workflow procederá com a efetiva¸cão do pagamento dos produtos. O pagamento é realizado em duas etapas. Primeiramente, será autorizado o débito no cartão de crédito do usuário do montante total dos produtos, através de um servi¸co de autoriza¸cão de pagamento. Após a autoriza¸cão do débito no cartão de crédito, o pagamento é informado através da invoca¸cão do servi¸co pay.

Ambos os workflows W1 e W2 podem ser executados em paralelo uma vez que n˜ao

há dependência de dados entre eles. Após o término da execu¸cão paralela dos workflows W1 e W2, é executado o workflow W3, o qual é responsável pelo agendamento da entrega

dos produtos. O agendamento da entrega depende das informa¸cões produzidas pelos workflows W1 e W2, i.e., das informa¸cões do perfil do usuário (produzidas pelo workflow

W1) e da fatura dos produtos (produzida pelo workflow W2).

O dom´ınio da aplica¸cão de comércio eletrônico (Congo) considerado aqui é repre- sentado por uma base de conhecimento denominada KB@ = hT@, A@i. O componente

terminol´ogico T@ da base KB@ descreve os conceitos usados para expressar o vocabul´ario

do dom´ınio assim como o relacionamento entre eles. O componente assercional A@ con-

templa os fatos descrevendo o estado do mundo. A defini¸c˜ao dos conceitos est´a ilustrada na Figura 6.

A terminologia usada no exemplo ´e definida a partir dos conjuntos de s´ımbolos NC,

1 ( 2 i f not R e g i s t e r e d ( c r e d ) then 3 c r e a t e A c c t (< c r e d >, <s >) 4 5 s i g n I n (< c r e d >, <s >) ; 6 l o a d P r o f i l e (< c r e d >, <p r o f >) 7 ) 8 | | 9 ( 10 g e t P r o d u c t S p e c i f i c a t i o n (<>,<prodSpec >) 11 ; 12 w h i l e P r o d u c t S p e c i f i c a t i o n ( prodSpec ) do 13 ( 14 s e a r c h (<prodSpec >, <product >) ; 15 16 i f ( I n S t o c k ( p r o d u c t ) ) 17 p u t I n C a r t (< product >, <totalAmount >) ; 18 19 g e t P r o d u c t S p e c i f i c a t i o n (<>,<prodSpec >) 20 ) 21 ;

22 w h i l e not ( ChargedCard o r NotAuthorized ) ( c c ) do

23 (

24 a u t h o r i z e (<cc , totalAmount >, <auth >)

25 ) ;

27 pay (<auth >, <inv >)

28 )

29 ;

30 s c h e d u l e D e l i v e r y (< p r o f , inv >, <d e l i v >)

Figura 5: Se¸cão de defini¸cão do workflow para o exemplo de comércio eletrônico. definidos, respectivamente.

NC = {CreditCard, Authorization, Invoice, Credential, OpenSession, P roduct,

ClosedSession, Address, InStock, OutOf Stock, P roductSpecif ication NP = {hasCharge, hasP ayment, hasDeliveryInP rogress,

hasLogin, hasP roductAvailable}

Ndef = {ChargedCard, P aidInvoice, P aymentM ethod, ScheduledDelivery, Session,

Registered, Logged}

A terminologia é composta por um conjunto de axiomas de equivalência, conforme ilustrado na Figura 6. O conceito ChargedCard expressa um conceito representando os cartões de crédito que possuem algum débito. Formalmente, o conceito ChargedCard define o conjunto de indiv´ıduos do dom´ınio que são parte da extensão do conceito Cre-

ditCard e que est˜ao relacionados, atrav´es da propriedade hasCharge, a outro indiv´ıduo

pertencente à extensão do conceito Authorization. O conceito PaidInvoice denota um conceito representando as faturas quitadas. Formalmente, o conceito define o conjunto de indiv´ıduos do dom´ınio que pertencem à extensão do conceito Invoice e que estão relacio- nados, através da propriedade hasPayment, a outro indiv´ıduo pertencente à extensão do

ChargedCard ≡ CreditCard ⊓ ∃hasCharge.Authorization P aidInvoice ≡ Invoice ⊓ ∃hasP ayment.P aymentM ethod P aymentM ethod ≡ CreditCard ⊔ Authorization

ScheduledDelivery ≡ Delivery ⊓ ∃hasDeliveryInP rogress.Address Session ≡ OpenSession ⊔ ClosedSession

Registered ≡ Credential ⊓ ∃hasLogin.Session Logged ≡ Credential ⊓ ∃hasLogin.OpenSession

Figura 6: Componente terminol´ogico (TBox) da base de conhecimento K@.

conceito PaymentMethod. O conceito PaymentMethod denota o conjunto de indiv´ıduos do dom´ınio que pertencem à extensão do conceito CreditCard ou do conceito Authorization. O conceito ScheduledDelivery denota o conjunto de indiv´ıduos do dom´ınio que perten- cem à extensão do conceito Delivery e que estão relacionados, através da propriedade

hasDeliveryInProgress, a outro indiv´ıduo pertencente `a extens˜ao do conceito Address. O

conceito Session denota o conjunto de indiv´ıduos do dom´ınio que pertencem `a extens˜ao do conceito OpenSession ou do conceito ClosedSession. Por fim, os conceitos Registered e

Logged possuem defini¸c˜oes semelhantes, diferenciando-se apenas no conceito usado para

expressar a restri¸cão existencial. Ambos os conceitos denotam um conjunto de indiv´ıduos do dom´ınio que pertencem à extensão do conceito Credential e que estão relacionados, através da propriedade hasLogin, a outro indiv´ıduo pertencente à extensão do conceito

Session (no caso do conceito Registered ) ou do conceito OpenSession (no caso do conceito Logged ).

Observe que o TBox considerado neste exemplo é ac´ıclico e não contém axiomas de

inclusão de conceito arbitrário C ⊑ D. Estas restri¸cões nos axiomas da terminologia são

necessárias para evitar problemas semânticos na atualiza¸cão da base de conhecimento, o que poderia produzir resultados inesperados e pouco intuitivos. Os problemas decorrentes de atualiza¸cões envolvendo terminologias c´ıclicas são discutidos na se¸cão 2.1.1.2.

No documento Certificação de composições de serviços web semânticos (páginas 50-64)