Modelo de Informação

O processo de modelagem descrito nessa tese segue as diretivas do Object

Management Group (OMG)1_{. A GKB distingue para cada nome a entidade que} representa. A noção de entidade usada nessa tese é a definida na normaISO19109

(2006):

um objeto com significado no domínio de discurso.

No domínio geográfico, países, cidades e municípios são exemplos de tais objetos. Na GKB, entidades e seus nomes são classes distintas e cada entidade está associada a um tipo de entidade. Por exemplo, a entidade ‘concelho de Faro’ está associada ao tipo de entidade ‘concelho’ e ao nome ‘Faro’.

Como na ISO 19109, as entidades são classificadas segundo tipos de entidades com base em conjuntos de características ou propriedades comuns. Esta aborda- gem capacita a GKB a suportar relacionamentos ‘vários para um’ entre nomes e entidades. Esta flexibilidade também permite a incorporação de novos tipos de dados.

Um modelo é uma abstração de um fenômeno no mundo real, e um meta- modelo é ainda outra abstração, que serve para caracterizar conceitos utilizados na definição do modelo. A Figura 3.2 apresenta o meta-modelo base da GKB, o qual é suficientemente genérico para representar informação de qualquer domínio. O meta-modelo base constitui-se das principais classes usadas para modelar qualquer domínio de conhecimento que seja representado na GKB, ou seja, é o núcleo do modelo.

Uma entidade geográfica Feature é composta por um nome Name e um tipo

Type. A classe Feature é associada com a classe Type (p. ex. a entidade Douro é

um tipo de rio). A classe Relationship-Type captura relacionamentos suportados entre tipos e entidades (p. ex. parte de e adjacência entre outros de natureza geográfica). A classe Type-Relationship armazena os relacionamentos entre tipos (p. ex. um concelho é parte de um distrito). A classe Feature-Relationship armazena os relacionamentos entre entidades (p. ex. Sintra (concelho) é parte de Lisboa (distrito)).

1

Figura 3.2: Meta-modelo base da informação na GKB.

As entidades podem ser especializadas por Feature-Footprint, a qual captura as coordenadas geográficas. As coordenadas podem identificar centroides, caixas limitadoras ou polígonos. A entidade Serra da Estrela, por exemplo, tem o centroide em 40°20N, 7°38W.

3.2.2.1 Representação de Atributos e Nomes

A Figura 3.3 representa o modelo base da Figura 3.2 estendido com as classes usadas para representar atributos de tipos, entidades e nomes. Diferentes tipos geográficos têm diferentes atributos. Uma cidade tem população, um rio tem uma nascente e uma montanha tem uma altitude, por exemplo. As classes Type-Attribute, Feature-Attribute e Name-Attribute adicionam conjuntos de propriedades às classes Type, Feature e Name, respectivamente, do modelo base.

Cada nome capturado na classe Name está associado com uma língua e um código de país associado a ele (p. ex. PT-BR). O código da língua adotado segue o padrão de etiquetas de língua <código da língua“–”código do país> definido pela RFC 3066 da IETF (Alvestrand, 2001). Os nomes podem ser estendidos com conjuntos de atributos capturando preferências (p. ex. um nome é preferido

3.2 Projeto Conceitual da GKB

Figura 3.3: Representação de nomes e atributos na GKB.

ou alternativo), tempo (p. ex. histórico), uso (p. ex. raro, coloquial) e gentílicos. Esses atributos são armazenados na classe Name-Attribute.

Por exemplo, o rio Tajo tem seu equivalente em português Tejo e seu nome histórico Tagus, do Latin. O atributo histórico é capturado na classe Name-

Attribute, enquanto a classe Name armazena os nomes (Tajo, Tejo e Tagus), as

línguas (ES, PT e LA) e os códigos de país (ES e PT), respectivamente.

Finalmente, a classe Feature também armazena no atributo prep as palavras de ligação (p. ex. ‘de’, ‘da’ e ‘dos’) que compõem os nomes das entidades geográficas. Essas palavras de ligação são bastante relevantes para sistemas de REM, por exemplo, uma vez que auxiliam na identificação de nomes de locais em textos.

3.2.2.2 Relacionamentos Inter-Domínio

Relacionamentos inter-domínio são conexões entre diferentes domínios modelados na GKB. A Figura3.4apresenta o modelo representando os relacionamentos inter- domínio.

A informação armazenada nas classes apresentadas na Figura 3.4 está assim distribuída: a classe Adm-Feature contém informação do domínio administrativo, a classe Phy-Feature armazena informação do domínio físico e a classe Net-Feature captura informação do domínio internet.

Todos os tipos de relacionamentos inter-domínio são armazenados na classe

ID-Type-Relationship (p. ex. parte-de e adjacência). As classes ID-Feature- Relationship-Adm-Phy e ID-Feature-Relationship-Phy-Adm capturam os relaci-

onamentos entre entidades do domínio administrativo e físico. Quando uma entidade do domínio administrativo é parte-de uma entidade do domínio físico

Figura 3.4: Relacionamentos inter-domínio na GKB.

o relacionamento é capturado na classe ID-Feature-Relationship-Adm-Phy, caso contrário utiliza-se a classe ID-Feature-Relationship-Phy-Adm. Relacionamentos do tipo adjacência podem ser armazenados em qualquer uma das classes. Um exemplo de relacionamento inter-domínio é: os concelhos de Lisboa e Setúbal (domínio administrativo) são adjacentes ao rio Tejo (domínio físico). Outros relacionamentos tais como cruza, toca e intersecta estão implícitos nas coor- denadas dos dados e não são modelados na GKB.

Por outro lado, quando os domínios envolvidos são o administrativo e o de internet, os relacionamentos são capturados na classe ID-Feature-Relationship-

Adm-Net. Esses relacionamentos permitem tornar explícito o âmbito geográfico

de sítios e domínios da internet. A classe ID-Feature-Relationship-Adm-Net armazena os identificadores das entidades do domínio internet e do domínio geográfico administrativo com o relacionamento tem-âmbito.

3.2.2.3 Procedência dos Dados

Um dos requisitos da GKB é suportar o rastreamento da informação, ou seja, possibilitar a uma aplicação encontrar a proveniência dos dados. Tão importante quanto o dado em si, é a fonte de informação da qual esse dado foi extraído. No modelo da GKB as fontes de informação estão distribuídas por todo o modelo, conforme mostra a Figura 3.5. As fontes de informação são independentemente