Uma introdução aos Mapas de Tópicos

  • Artigo

Kal Ahmed e Graham Moore

Introdução

Este artigo introduz a norma internacional ISO Mapas de Tópicos. O paradigma mapas de tópicos descreve a maneira como relacionamentos complexos entre conceitos abstratos e recursos do mundo real podem ser descritos e permutados usando uma sintaxe XML padrão.

Os mapas de tópicos foram originalmente desenvolvidos no final da década de 1990 como uma maneira de representar estruturas de índices no final do livro, de modo que vários índices de origens diferentes pudessem ser mesclados. Porém, os desenvolvedores rapidamente perceberam que com uma pequena generalização adicional poderiam criar um metamodelo com aplicação potencialmente muito mais ampla. O resultado desse trabalho foi publicado em 1999 como ISO/IEC 13250-Topic Navigation Maps.

Além de descrever o modelo básico dos mapas de tópico e os requisitos para um processador de mapa de tópicos, a primeira edição da ISO 13250 incluía uma sintaxe de intercâmbio baseada em SGML e a linguagem de ligação de hipermídia conhecida como HyTime. A segunda edição, publicada em 2002 [1], adicionou uma sintaxe de intercâmbio baseada em XML e Xlink. Essa é a sintaxe com o suporte mais amplo até o momento nos produtos de processamento de mapas de tópicos e é a sintaxe que iremos descrever neste artigo. Hoje existe uma série de implementações da norma, tanto em fonte aberta quanto patenteadas, para diversas linguagens e plataformas, incluindo a plataforma .NET.

Conceitos básicos dos mapas de tópicos

A essência dos mapas de tópicos pode ser resumida de forma muito sucinta: Um mapa de tópicos consiste em uma coleção de tópicos, cada um representando algum conceito. Os tópicos estão relacionados uns aos outros por associações, que são combinações de tópicos de tipo n-ary. Um tópico também pode estar relacionado a qualquer número de recursos por suas ocorrências.

A Figura 1 mostra os três conceitos básicos dos mapas de tópicos. Também mostra como a distinção entre os relacionamentos tópico com tópico e tópico com recurso permite uma partição do modelo em um espaço de tópicos que contém somente tópicos e associações entre tópicos e um espaço de recursos que contém os recursos relacionados aos tópicos.

Essa partição é interessante porque permite que um mapa de tópicos desenvolvido para um conjunto de recursos seja adaptado para indexar um conjunto de recursos diferente. Dessa maneira, o mapa de tópicos pode ser considerado como uma forma portátil de conhecimento.

Ao contrário dos modelos específicos de domínio, o modelo de mapa de tópicos não possui um conjunto de tipos predefinido. Em vez disso, autores de mapas de tópicos individuais ou grupos de autores em uma comunidade de prática podem definir o modelo do seu domínio de interesse e compartilhar esses modelos com outros autores de outros domínios.

Aa480048.MapasDeTopicos_01(pt-br,MSDN.10).jpg
Figura 1

Aa480048.MapasDeTopicos_02(pt-br,MSDN.10).jpg
Figura 2

Acreditamos que para muitos usuários finais, um bom aplicativo de mapas de tópicos irá ocultar grande parte do mecanismo dos mapas do tópicos, ou todo ele, permitindo aos usuários concentrar-se nos modelos de domínio com que trabalham. No entanto, o modelo de mapas de tópicos e a norma Mapas de Tópicos oferecem uma série de benefícios que podem ser revelados em aplicativos e podem constituir pontos de venda exclusivos.

A metáfora principal dos mapas de tópicos de tópicos, ocorrências e associações alcança um equilíbrio entre ser compacto e fácil de entender e fornecer infra-estrutura básica suficiente para permitir aos usuários converter o seu modelo mental de domínio em um modelo de mapa de tópicos. Outras formas de organização de dados e informações como RDF e o modelo relacional podem possuir um modelo mais simples ainda, mas exigem que o usuário crie infra-estrutura para procedimentos comuns como rotular um item com alguns nomes, definir uma estrutura de classes ou criar relacionamentos n-ary entre itens.

Como descrito acima, o modelo de mapas de tópicos possui uma distinção clara entre o modelo de domínio, expresso como tópicos e associações entre tópicos, e os recursos indexados, expressos como ocorrências que ligam tópicos a recursos. Três benefícios principais podem resultar dessa estrutura:

  • O mapa de tópicos pode atuar como uma visão geral de alto nível do conhecimento de domínio contido em um conjunto de recursos. Desse modo, o mapa de tópicos pode servir não somente como um guia para localizar recursos para o especialista, mas também como uma maneira para os especialistas modelarem seu conhecimento de uma forma estruturada. Isso permite aos não especialistas aprender os conceitos básicos e seus relacionamentos antes de aprofundar nos recursos que fornecem mais detalhes.

  • Um mapa de tópicos pode ser facilmente segmentado, dependendo dos recursos que estão disponíveis. Alguns editores utilizam um índice baseado em mapa de tópicos de grandes conjuntos de recursos e criam de forma dinâmica o índice apropriado quando publicam um subconjunto desses recursos. Com uma modelagem ponderada é até possível criar diferentes camadas de detalhe em um mapa de tópicos e diferenciar entre produtos de informação baseados na indexação e recursos de navegação que eles fornecem, além do conteúdo informativo dos produtos.

  • Mapas de tópicos que indexam diferentes conjuntos de recursos podem ser facilmente combinados. Esse recurso pode ser usado para permitir às organizações “importar” dados e índices de terceiros e integrar sem interrupção seus próprios dados e índices.

Como já observado, a norma Mapas de Tópicos não vem com uma ontologia predefinida. Não existem restrições quanto aos domínios nos quais os tópicos de mapas podem ser aplicados e há relativamente poucas limitações mesmo na abordagem de modelagem tomada.

Intercâmbio Simplificado

Temos visto mapas de tópicos utilizados para modelar relacionamentos temporais entre eventos; relacionamentos entre conceitos abstratos e suas representações; e formas de lógica de primeira ordem, além de relacionamentos mais tradicionais como dicionários de sinônimos, vocabulários controlados e informações comerciais.

Para muitos usuários, o fato de que os mapas de tópicos podem ser intercambiados utilizando uma sintaxe padrão baseada em XML fornece um forte benefício no aprimoramento da portabilidade de seus dados entre aplicativos e plataformas. Além disso, a sintaxe de intercâmbio XML permite uma fácil integração do intercâmbio de informações do mapa de tópicos dentro da arquitetura de Web Services.

Existem três benefícios principais que os arquitetos e desenvolvedores de sistemas podem obter com a aplicação do paradigma dos mapas de tópicos, que podem ser resumidos como “Flexibilidade, flexibilidade e flexibilidade”.

Os mapas de tópicos fornecem o metamodelo no qual um modelo de aplicativo completamente flexível pode ser construído. A criação de novos tipos de objetos comerciais pode ser conseguida adicionando dados à ontologia que constrói o mapa de tópicos.

Como a ontologia é expressa como tópicos e associações entre tópicos, a extensão da ontologia torna-se uma questão de adicionar dados, não uma questão de redesenhar o esquema de armazenamento de base. Isso torna possível modificar o modelo de dados usado por um aplicativo sem a necessidade de atualizar armazenamentos persistentes implantados.

Com os dados do aplicativo armazenados em um metamodelo padronizado e extensível, o caminho está aberto para permitir integração e extensão muito mais simples de aplicativos de terceiros. Esse modelo permitiria a um desenvolvedor de terceiros definir seus próprios dados e extensões de código para um aplicativo sem depender do esquema do aplicativo central que suporta as estruturas de dados específicas da extensão.

Aa480048.MapasDeTopicos_03(pt-br,MSDN.10).jpg
Figura 3

Além de permitir extensões de terceiros ao esquema do aplicativo, a flexibilidade da estrutura de mapas de tópicos pode ser usada para permitir aos usuários criar suas próprias extensões. Isso tem dois efeitos:

  • Permite que os aplicativos sejam altamente personalizáveis: permitindo integração muito mais fácil dos sistemas de dados específicos do cliente, por exemplo. Consideramos isso como sendo a chave para aplicativos verticais que podem ser mais facilmente implantados para vários clientes. Por exemplo, um aplicativo de mapas de tópicos de grande sucesso foi produzido por um editor de informações jurídicas para o mercado de serviços financeiros. O ponto de venda exclusivo desse produto baseado em mapas de tópicos é que é possível integrar a documentação de procedimentos e marketing dos seus clientes com as informações jurídicas que fornecem.

  • Isso permite o desenvolvimento de aplicativos horizontais que podem ser integrados mais facilmente nos ambientes existentes.

Um tópico é uma representação de um conceito que pode ser processada por máquina. A norma Mapas de Tópicos não restringe de forma alguma o conjunto de conceitos que podem ser representados como tópicos. Normalmente os tópicos são usados para representar recursos eletrônicos (como documentos, páginas da Web, Web Services) e recursos não eletrônicos (como pessoas ou lugares). Os tópicos podem igualmente ser usados para representar coisas que não possuem forma tangível, como empresas, eventos e conceitos abstratos como “pensões” ou “seguro”.

Formas de Identidade

Os tópicos possuem quatro formas de identidade principais. Um tópico pode possuir zero ou mais de cada uma dessas formas de identidade e, desse modo, pode ser identificado dentro de um sistema de mapas de tópicos por um número de diferentes maneiras:

  • Identidade como um recurso de tópico em um mapa de tópicos serializado. Quando um mapa de tópicos é representado de forma serializada para intercâmbio, cada tópico recebe um identificador URI que é exclusivo nesse mapa de tópicos. Esses URIs são usados principalmente para referências desserializantes entre tópicos. Esses identificadores são denominados localizadores de origem.

  • Identidade como um rótulo que pode ser lido por humano. Um tópico pode ter qualquer quantidade de nomes de tópico. Os nomes atuam como rótulos para consumo humano e podem ser texto ou uma referência a alguma representação não textual (por exemplo, um ícone, um clip de som, um clip de animação etc.). O mecanismo escopo (descrito mais adiante) permite o caso de homônimo (onde uma única palavra é usada para referir a dois ou mais conceitos diferentes).

  • Identidade por referência. Quando um tópico for usado para representar um recurso que já possui seu próprio URI exclusivo, esse URI pode ser usado como parte da identidade do tópico. Isso é simplesmente uma maneira de dizer ao agente processador que “Esse tópico representa esse recurso.” Na norma de mapas de tópicos, essa forma de identificador é conhecida como localizador de objeto.

  • Identidade por descrição. Os tópicos podem ser usados para representar um conceito que não possui o seu próprio URI exclusivo. Muitas das coisas que um tópico pode representar nunca poderiam possuir um URI exclusivo porque não são coisas para as quais um computador pode resolver uma referência. Por exemplo, uma pessoa pode possuir qualquer quantidade de registros de banco de dados sobre si mesmo ou biografias ou fotos on-line, mas nenhum desses recursos aos quais se pode dar um endereço é a pessoa, são meramente uma forma de descritor da pessoa. Na norma de mapa de tópicos, essa forma de identificador é conhecida como identificador de objeto e o recurso ao qual o identificador de objeto resolve é conhecido como indicador de objeto. Os mapas de tópicos permitem o uso de referências de URI a esses recursos descritivos como uma forma de identidade. Obviamente é importante que o autor do mapa de tópicos escolha recursos descritivos não ambíguos para essa finalidade; voltaremos mais adiante a essa questão.

A distinção entre as duas últimas formas de identidade pode ser confusa. Considere o URL http://www.networkedplanet.com/about/ index.html. Essa é uma página da Web que descreve a empresa NetworkedPlanet. Assim, esse URL poderia ser usado como o identificador de objeto de um tópico denominado “A empresa NetworkedPlanet” porque resolve para um recurso que descreve o conceito da empresa. No entanto, se desejássemos falar sobre o conceito "A página 'Sobre' no site www.networkedplanet.com," na realidade desejamos um tópico cujo objeto realmente seja o recurso no endereço http://www.networkedplanet.com/about/index.html, por isso usaríamos o mesmo URI que o localizador de objeto.

Tipos e Nomes

A diferença principal entre um identificador de objeto e um localizador de objeto é que um identificador de objeto requer interpretação humana como um recurso para determinar o conceito que um tópico representa, enquanto que um localizador de objeto simplesmente aponta para o conceito que o tópico representa. Isso é mostrado na Figura 2. A seta sólida escura mostra o uso de um recurso como localizador de objeto. A seta sólida clara mostra o uso do mesmo recurso como identificador de objeto. As setas pontilhadas finas mostram a função do ser humano na interpretação de um identificador de objeto.

Embora um único tópico possa ter muitas formas de identidade, é importante observar que cada identificador separado pode resolver para apenas um tópico. As regras de mesclagem de mapas de tópicos (descritas mais adiante) aplicam esse relacionamento de um para muitos entre tópicos e seus identificadores.

Além dessas formas de identidade, um tópico também pode possuir qualquer quantidade de tipos e qualquer quantidade de nomes.

Os tipos de um tópico definem a classe (ou classes) de conceito ao qual pertence o conceito representado pelo tópico. Os tipos são tratados nos mapas de tópicos como conceitos; desse modo, todo tipo é representado por um tópico. O tipo de um tópico é especificado simplesmente por uma forma de relacionamento privilegiada entre o tópico que representa a instância e o tópico que representa o tipo.

Aa480048.MapasDeTopicos_04(pt-br,MSDN.10).jpg
Figura 4

Os nomes de um tópico definem um conjunto de rótulos de um tópico. Todo nome possui uma estrutura hierárquica. Na raiz está o nome base, que possui uma representação de seqüência. É o valor de seqüência do nome de base que é usado para determinar a identidade de tópico pelo rótulo. Um nome base também é um contêiner de qualquer quantidade de formas alternativas (conhecidas como nomes variantes). As formas alternativas de um nome podem ser valores de seqüência ou referências a recursos, permitindo que representações como ícones ou clipes de som sejam referenciados como nomes variantes. Os nomes base e nomes variantes podem ter um contexto (ou escopo) no qual são válidos, permitindo que um aplicativo ciente de mapas de tópicos selecione o melhor nome para apresentar a um usuário em uma situação determinada. Esse escopo será abordado mais adiante.

Associações

Associações são a forma geral da representação de relacionamentos entre tópicos em um mapa de tópicos. Uma associação pode ser considerada como um agregado de tópicos n-ary. Ou seja, uma associação é um agrupamento de tópicos sem uma direção ou ordem implícita e não existe restrição quanto ao número de tópicos que podem ser agrupados.

Um tipo (definido por um tópico) pode ser atribuído a uma associação, e especifica a natureza do relacionamento representado pela associação. Além disso, cada tópico que participa da associação desempenha uma função de tipo que especifica a maneira como o tópico participa.

Por exemplo, para descrever o relacionamento entre uma pessoa, "João Silva," e a empresa para a qual ele trabalha, "ABC Limitada," criaríamos uma associação tipificada pelo tópico "Emprego" e com os tipos de funções "Empregado" (para a função desempenhada por "João Silva") e "Empregador" (para a função desempenhada por "ABC Limitada").

Como os nomes, a uma associação pode ser atribuído um escopo no qual seja válida e que pode ser usado por um aplicativo ciente de mapas de tópicos para determinar se deve exibir as informações representadas pela associação a um usuário em uma situação determinada.

Ocorrências

As ocorrências são usadas para representar ou para referir a informações sobre um conceito representado por um tópico. As ocorrências podem ser usadas para armazenar dados de seqüência em um mapa de tópicos ou para referenciar qualquer tipo de recurso endereçável na Web externo ao mapa de tópicos. Nenhuma restrição é colocada sobre qual tipo de recurso é tratado por uma ocorrência. Pode ser uma página HTML estática, uma página HTML gerada por ASP, um Web Service ou qualquer outro tipo de recurso. As ocorrências também não são restringidas ao protocolo HTTP - qualquer endereço codificado como um URI pode ser usado para abordar um recurso externo. Mais uma vez, as ocorrências podem ser tipificadas, usando um tópico para expressar o tipo de ocorrência e um escopo de validade também pode ser atribuído a uma ocorrência.

Escopo

Escopo é o termo usado na norma de mapas de tópicos para referir a uma restrição ou um contexto no qual alguma coisa é dita sobre um tópico. A maneira como essas instruções sobre tópicos são feitas é adicionando um nome ao tópico; especificando uma ocorrência para um tópico; ou criando uma associação entre tópicos (nesse caso a instrução aplica-se a todos os tópicos da associação).

Em muitos casos as instruções não são sempre verdadeiras, mas dependem de um contexto. Por exemplo, fazemos afirmações como "ABC Limitada foi o principal fornecedor de coisas em Q2 2004," ou "Fred diz que ABC Limitada é um bom investimento." Nessas instruções o contexto é mostrado em itálico: um contexto temporal no primeiro caso e um contexto de citação no segundo caso. De forma mais prosaica, o contexto geralmente é usado para facilitar interfaces de vários idiomas, de modo que o conceito “cachorro” possa ter o rótulo “dog” no contexto do idioma inglês, ”le chien” em francês e ”das hund” em alemão.

Em um mapa de tópicos, o escopo é definido por uma coleção de tópicos que podem ser atribuídos a um nome, uma ocorrência ou uma associação. O escopo padrão (onde nenhum conjunto é atribuído) é conhecido como o escopo não restringido e significa simplesmente que o nome, a ocorrência ou a associação são sempre válidos.

Quando um aplicativo ciente de mapas de tópicos encontra um nome, ocorrência ou associação que tenha um escopo atribuído, o aplicativo deve utilizar as informações que possui sobre o contexto operacional atual e comparar essas informações com as informações do escopo contidas no mapa de tópicos para determinar se a construção é válida e se deve ser apresentada ao usuário.

Na edição atual da ISO 13250, a mecânica de processamento do escopo em relação a um contexto do aplicativo não é restringida pela norma , sendo que muitos desenvolvedores de mapas de tópicos consideram isso uma desvantagem, pois pode dificultar o intercâmbio de mapas de tópicos que utilizam escopo. A próxima revisão da norma irá recomendar que um escopo que consiste em vários tópicos deve ser processado de forma que a construção do escopo seja válida somente se o aplicativo determinar que todos os tópicos do escopo aplicam-se ao contexto do aplicativo atual.

Lista 1. A sintaxe XML define um elemento topicMap que contém qualquer quantidade de tópicos e elementos de associação. Um exemplo simples de mapa de tópicos em sintaxe XTM é mostrado a seguir.

-->
<!-- The Clash is a Band -->
<topic id="clash">
<instanceOf>
<topicRef xlink:href="#band"/>
</instanceOf>
<baseName>
<baseNameString>The Clash</baseNameString>
</baseName>
</topic>
<!-- Joe Strummer is a Person (note multiple names)
-->
<topic id="joe-strummer">
<instanceOf>
<topicRef xlink:href="#person"/>
</instanceOf>
<baseName>
<scope>
<topicRef xlink:href="stage-name"/>
</scope>
<baseNameString>Joe Strummer</baseNameString>
</baseName>
<baseName>
<baseNameString>Joseph Mellor</baseNameString>
</baseName>
</topic>
<!—
Joe Strummer is a member of The Clash -->

Note separate member elements
used for the different roles
played
-->
<association>
<instanceOf>
<topicRef xlink:href="#membership"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#group"/>
</roleSpec>
<topicRef xlink:href="#clash"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#singer"/>
</roleSpec>
<topicRef xlink:href="#joe-strummer"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#guitarist"/>
</roleSpec>
<topicRef xlink:href="#joe-strummer"/>
</member>
</association>
</topicMap>

Mesclagem de tópicos

Mesclagem automática de tópicos é um recurso importante dos mapas de tópicos que traz muitos benefícios ao desenvolvimento de mapas de tópicos e aos aplicativos que utilizam mapas de tópicos para gerenciar e trocar dados.

O princípio por trás da mesclagem de tópicos é que, em qualquer mapa de tópicos determinado, cada objeto descrito pelo mapa de tópicos deve ser representado por um e apenas um tópico no mapa de tópicos. Isso significa que é responsabilidade do processador de mapas de tópicos tentar identificar a situação em que dois tópicos representam o mesmo objeto e processá-los de forma que somente um tópico permaneça. Esse é o processo de mesclagem.

A identificação de quando dois tópicos representam o mesmo objeto é conseguida aplicando-se heurística. A norma de mapas de tópicos define um conjunto de heurística básica:

  1. Se dois tópicos compartilharem o mesmo localizador de origem, eles foram analisados da mesma origem de mapa de tópicos e devem ser considerados como representando o mesmo conceito.

  2. Se dois tópicos possuírem o mesmo localizador de objeto, ambos identificam o mesmo recurso de rede como sendo o que eles representam.

  3. Se dois tópicos possuirem o mesmo indicador de objeto, ambos estão utilizando o mesmo recurso para descrever o conceito que representam e devem ser considerados como representando o mesmo conceito.

  4. Se dois tópicos possuirem um nome base cada um com a mesma representação de seqüência e o escopo dos nomes base for o mesmo conjunto de tópicos, os tópicos devem ser considerados como representando o mesmo conceito.

  5. Finalmente, um aplicativo de mapa de tópicos pode utilizar qualquer informação específica de domínio que possua para determinar se dois tópicos representam o mesmo conceito.

O item (3) na lista acima ressalta a importância de selecionar um bom recurso como a descrição de um conceito. Se a descrição for de algum modo ambígua ou se o recurso tratado não estiver suficientemente definido, é possível que dois autores de mapas de tópicos diferentes possam usar o mesmo recurso como um descritor de conceitos diferentes, resultando em mesclagem indesejada. Na nossa experiência, os bons recursos para descritores de objeto são os criados especificamente para descrever um único objeto: as páginas em wikipedia.org, por exemplo, ou páginas criadas pelos autores de mapas de tópicos ou por uma comunidade de praticantes para definir um vocabulário controlado.

O item (4) mostrou-se controverso na comunidade dos mapas tópicos, pois se apóia no que muitos consideram uma forma de identidade relativamente fraca: o nome de um conceito em algum idioma. O mapeamento de palavras de um idioma para conceitos é um assunto complexo, pois existe o desafio de várias palavras possuindo significados diferentes (homônimos), para não mencionar os desafios de localização! Na próxima versão da norma ISO, as restrições à identidade baseada em nome serão mais rígidas ainda para exigir que um autor sinalize explicitamente um nome de tópicos como sendo o que deve ser usado para conferir uma identidade (o padrão sendo que um nome não irá conferir identidade ao seu tópico).

O item (5) permite que os aplicativos estendam o conjunto de critérios de mesclagem da norma Mapas de Tópicos com critérios específicos do aplicativo. Poderiam incluir critérios baseados em mais de uma seqüência direta ou comparação de URIs. Por exemplo, um aplicativo poderia saber que “O Duque” e “John Wayne” são nomes do mesmo ator e mesclar dois tópicos nessa base. Tendo identificado os tópicos a ser mesclados, o processo de mesclagem define o processo de substituir esses dois (ou mais) tópicos por um único tópico. O tópico único que resulta do processo de mesclagem possui todos os identificadores, nomes (incluindo nomes variantes) e ocorrência dos tópicos que são mesclados. Além disso, o tópico resultante substitui os tópicos mesclados toda vez que eles forem referenciados (ou seja, em quaisquer associações, escopos ou tipos em que apareçam). Esse processo é mostrado de forma esquemática na Figura 4.

A mesclagem com dois ou mais mapas de tópicos é simplesmente o processo de combinar seus conjuntos de tópicos e associações e, em seguida, aplicar as regras de mesclagem de tópicos ao resultado.

Intercâmbio e a sintaxe XTM

Como citado acima, a norma ISO Mapas de Tópicos define duas sintaxes de intercâmbio padrão, uma baseada em SGML e a outra baseada em XML. A sintaxe XML define um elemento topicMap que contém qualquer quantidade de tópicos e elementos de associação.

Um exemplo simples de mapa de tópicos em sintaxe XTM é mostrado a seguir:

<topicMap xmlns=
http://www.topicmaps.org/
xtm/1.0/ xmlns:xlink=
"http://www.w3.org/1999/
xlink">
<topic id="band">
<baseName>
<baseNameString>Band
</baseNameString>
</baseName>
</topic>
<topic id="person">
<baseName>
<baseNameString>Person
</baseNameString>
</baseName>
</topic>
<!--

Não entraremos nos detalhes da sintaxe aqui. O leitor interessado é direcionado à especificação original Mapas de Tópicos XML [2] produzida por TopicMaps.org (que foi depois adotada pela ISO).

Deve ser observado que a sintaxe XTM não impõe as restrições de mesclagem que são requeridas de um processador de mapas de tópicos. Isso permite que XTM seja criado facilmente, mas requer que qualquer processador capaz de ler um arquivo XTM deva detectar tópicos que devem ser mesclados e aplicar as regras de mesclagem durante a análise do arquivo XTM. Quando um arquivo XTM for considerado “totalmente mesclado” (ou seja, não contém elementos de tópicos representando tópicos que devem ser mesclados), o modelo de mapa de tópicos que ele contém pode ser facilmente acessado com o uso de ferramentas de processamento XML padrão como XSLT and Xquery. No entanto, não é o caso de que ferramentas de processamento XML padrão possam ser facilmente aplicadas a arquivos XTM onde for necessário mesclagem.

Apesar dos problemas com mesclagem, a sintaxe XTM serve a necessidade básica de permitir intercâmbio entre aplicativos de processamento de mapas de tópicos conformativos. Além disso, a sintaxe e as regras de mesclagem juntas são flexíveis o suficiente para permitir que partes de um mapa de tópicos sejam serializadas como documentos XTM separados e posteriormente recombinadas por meio de mesclagem [3].

Padrões de mapas de tópicos

Como esperamos ter demonstrado até este ponto, a norma Mapas de Tópicos fornece uma arquitetura de base bastante flexível para uma ampla variedade de aplicativos de gerenciamento de conhecimento e informações. Essa flexibilidade pode levar a confusão e à reinvenção constante de abordagens básicas de modelagem. Para tratar dessa questão, defendemos o desenvolvimento e uso de padrões dentro de aplicativos de mapas de tópicos. Dividimos os padrões em duas categorias amplas: Padrões de Design de Mapas de Tópicos que são padrões de modelagem de dados de mapas de tópicos; e Padrões de Aplicativos de Mapas de Tópicos que são padrões arquitetônicos para o uso de sistemas de processamento de mapas de tópicos.

O conceito básico de um Padrão de Design de Mapa de Tópicos apóia-se bastante nos padrões de design da engenharia de software. Um Padrão de Design de Mapa de Tópicos fornece uma ontologia focalizada e reutilizável que trata de um único problema. Mas existe um par de diferenças interessantes.

  • Um Padrão de Design de Mapa de Tópicos pode ser determinado com mais precisão do que um padrão de design de software, pois deve especificar os URIs dos identificadores de objeto dos tópicos principais usados pelo padrão. Dessa maneira, toda implementação de um padrão específico em um mapa de tópicos pode ser reconhecida instantaneamente pela presença de tópicos com os URIs especificados pelo padrão.

  • Como um mapa de tópicos é puramente constituído por dados, comportamentos relacionados a um Padrão de Design de Mapa de Tópicos são implementados não no próprio mapa de tópicos, mas no software de processamento que faz uso dos dados do mapa de tópicos. Alguns padrões de design podem aconselhar um conjunto de comportamentos específico para aplicativos de processamento; outros podem descrever apenas o modelo de dados e deixar em aberto a maneira como o aplicativo processa o modelo de dados.

Alguns padrões básicos retirados da Library Science foram definidos por um dos autores e recebem suporte de uma série de aplicativos de processamento de mapas de tópicos [4]. Esses padrões incluem a classificação hierárquica e de facetas. Mostramos aqui um exemplo desse padrão.

O Padrão adrão de Classificação Hierárquica utiliza uma propriedade de modelagem bastante útil dos mapas de tópicos. Ou seja, que todo tipo de tópico, associação e ocorrência é ele próprio um tópico. Esse recurso permite que a ontologia de um aplicativo de mapa de tópicos seja anotada com o uso da mesma estrutura que é usada para preencher a própria ontologia e pode ser usado para grandes efeitos nos padrões de design, permitindo que uma ontologia de mapa de tópicos existente seja anotada usando o padrão “metaontologia” em vez de modificado.

Esse padrão permite a um aplicativo processar um conjunto de associações entre tópicos como representando uma hierarquia.

Padrões de Aplicativos de Mapas de Tópicos

Os Padrões de Aplicativos de Mapas de Tópicos fornecem padrões arquitetônicos de alto nível e, principalmente, concentram-se na integração de um sistema de processamento de mapas de tópicos com outros sistemas de dados e aplicativos. Esses padrões incluem padrões para representar informações de sistemas de dados externos como dados de mapas de tópicos; padrões para a importação de informações de sistemas de dados externos; e padrões para a exportação e exibição de dados de mapas de tópicos.

Discutiremos os aplicativos de mapas de tópicos com mais detalhes em um próximo artigo.

No momento em que escrevemos, mais trabalho está sendo feito na ISO, tanto na norma Mapas de Tópicos quanto em um conjunto de normas acompanhantes

Embora a ISO/IEC 13250 tenha passado por uma revisão, o núcleo da norma permanece inalterado desde 1999, um grau de estabilidade razoável em comparação com muitas normas de Internet. No entanto, o comitê da ISO decidiu que a próxima versão da norma será uma retificação significativa na maneira como a norma é apresentada e uma retificação secundária da norma em si.

A norma ISO/IEC 13250 deverá ser dividida em uma série de partes distintas: Uma introdução não normativa; uma descrição formal do modelo de dados de base dos mapas de tópicos; uma sintaxe de intercâmbio baseada em XML/Xlink com uma descrição do processo de desserialização da sintaxe em uma instância do modelo de dados e serialização do modelo de dados em um documento que conforma à sintaxe de intercâmbio; e um algoritmo de concessão para o modelo de dados que pode ser usado em testes de conformidade do processador de mapas de tópicos. Espera-se que essa organização torne a norma mais acessível ao leitor e acrescente recursos que faltavam originalmente e foram percebidos como importantes para desenvolvimentos futuros (em particular, a especificação de modelo formal e o algoritmo de concessão).

As alterações na norma incluem a capacidade de aplicar tipos de dados a valores de ocorrência, incluindo a capacidade de inserir XML; a capacidade de declarar um subconjunto dos nomes de um tópico como nomes a serem usados para determinar a identidade do tópico; um modelo de escopo mais claro; e uma definição da sintaxe de intercâmbio em W3C XML Schema e Relax-NG, além de XML DTD

Além das alterações na ISO/IEC 13250, o comitê também iniciou trabalhos em duas normas acompanhantes. ISO/IEC 18408: TMQL (Topic Maps Query Language) definirá uma linguagem para consultar o modelo de dados de mapas de tópicos, permitindo a seleção de construções de mapas de tópicos (como tópicos e associações) e dos dados transportados por eles (nome do tópico ou valores de ocorrência, por exemplo). ISO/IEC 19756: TMCL (Topic Maps Constraint Language) define uma linguagem de esquema para mapas de tópicos que permitiria ao autor do esquema restringir as construções que podem aparecer em um mapa de tópicos e a maneira como elas devem relacionar-se umas com as outras. Do mesmo modo que XML, uma linguagem de esquema para mapas de tópicos permite validação e também aplicativos de edição mais inteligentes dirigidos por esquema.

Essas duas normas estão atualmente em um estágio inicial de desenvolvimento com requisitos definidos e, no caso da TMQL, foi criada uma proposta inicial para a linguagem.

O trabalho sobre a norma central e as linguagens de consulta e restrição pode ser seguido no site ISO Topic Maps [5].

Padrão de Classificação Hierárquica

Demonstrativo de problema

Muitos sistemas de classificação consistem em uma ou mais hierarquias dos objetos. Várias diferentes relações hierárquicas são possíveis entre parte e todo, mais amplo e mais restrito, e assim por diante. Embora as relações possam ser diferentes, a semântica hierárquica permanece a mesma. Um aplicativo que esteja lidando com múltiplos tipos de relacionamento hierárquico precisa de uma forma para identificar todos esses tipos.

Descrição do padrão

O padrão apresentado aqui para modelar um sistema de classificação hierárquica usa um tópico para representar cada classe no sistema. A hierarquia, então, é modelada criando-se associações entre classes subordinadas e superordinadas. Entretanto, reconhece-se que há uma ampla variedade de diferentes relações hierárquicas. Por esse motivo, o tipo de associações entre as classes subordinadas e superordinadas não são definidas por esse padrão.

Em vez disso, esse padrão define o tipo de todos esses tipos, e o tipo de todos os tipos de funções para as funções subordinadas e superordinadas.

A outra questão é como relacionar os itens classificados de acordo com esse esquema (as instâncias) e os tópicos que representam as classes. Se uma instância for representada por um tópico, então deve ser feita uma associação entre o tópico representando a classe e o tópico representando a instância. Para esse propósito, são introduzidos os tipos de tópico para representar a classificação de uma instância (“Classificado Como”) e as funções desempenhadas nessa relação (“Classificação” e “Instância”). Se a instância não estiver representada como um tópico, então deve ser usada uma ocorrência, e nesse caso o tipo de “instância” pode ser usado como um tipo de ocorrência mais que como um tipo de função de associação.

Análise

O padrão cria um meio de sinalizar um tipo de associação como sendo uma relação hierárquica, e de indicar qual função é a superordinada e qual é a subordinada. Isso pode ser feito externamente para o mapa de tópicos que define os tipos de associação e de função, permitindo que um mapa de tópicos preexistente seja integrado sem a necessidade de editá-lo. A semântica de classificação dos tipos “Classificado Como”, "Classificação” e “Instância” podem ser omitidos desse padrão, no qual a classificação não é o propósito da hierarquia. Por esse motivo, esses objetos estão definidos em um conjunto separado de PSI (com uma base URI diferente) dos objetos definidores da hierarquia.

PSIs para o padrão de classificação hierárquica

Os Identificadores de Objetos Publicados a seguir são usados pelo Padrão de Classificação Hierárquica.

Tipo de relação hierárquica

http://www.techquila.com/psi/hierarchy/\#hierarchical-relation-type

Um tipo de tipo de associação. As associações que são classificadas em tipos por um tópico que é uma instância desse tipo representam uma relação pai-filho entre dois ou mais tópicos.

Tipo de função superordenada

http://www.techquila.com/psi/hierarchy/\#superordinate-role-type

Um tipo de tipo de função de associação. O(s) participante(s) de uma função que é classificada em tipos por uma instância desse tipo em uma associação do tipo Tipo de Relação Hierárquica é(são) o elemento superior na hierarquia.

Tipo de função subordinada

http://www.techquila.com/psi/hierarchy/\#superordinate-role-type

Um tipo de função de associação. O(s) participante(s) de uma função que é classificada em tipos por uma instância desse tipo em uma associação do tipo Tipo de Relação Hierárquica é(são) o elemento subordinado na hierarquia.

Classificado como

http://www.techquila.com/psi/classification/\#classifed-as

Um tipo de associação que afirma as relações entre um tópico que representa uma classe em um sistema de classificação (desempenhando a função Classificação) e um ou mais tópicos que representam instâncias dessa classe (desempenhando a função Instância).

Classificação

http://www.techquila.com/psi/classification/\#classification

A função desempenhada por um tópico que representa uma classe em um esquema de classificação.

Instância

http://www.techquila.com/psi/classification/\#instance

A função desempenhada por um tópico que representa um objeto que é classificado conforme um esquema de classificação.

Resumo

Este artigo introduziu o paradigma dos mapas de tópicos no contexto da norma ISO. Apresentamos os componentes principais do modelo de mapas de tópicos, mostrando como os componentes de processamento padrão de escopo e mesclagem de tópicos fornecem poder adicional a esse modelo.

Em um próximo artigo apresentaremos alguns casos de uso concretos de mapas de tópicos e mostraremos como o modelo de mapas de tópicos pode ser usado para tratar muitas das necessidades de organização e intercâmbio de informações de um ambiente comercial moderno.

Notas de rodapé

1. A palavra ontologia neste contexto significa o sistema de tipos de tópicos, ocorrências e associações que juntos definem as classes e de coisas e os relacionamentos entre coisas que são documentadas por um mapa de tópicos.

Sobre os autores

Kal Ahmed trabalhou em gerenciamento de informações SGML e XML durante dez anos, fazendo desenvolvimento de software e consultoria . Ele é bem o conhecido na comunidade de mapas de tópicos pelo seu trabalho sobre o kit de ferramentas de mapas de tópicos Java de fonte aberta, TM4J(http://www.tm4j.org/) e pelas suas contribuições no desenvolvimento da norma ISO. Kal publicou muitos artigos sobre mapas de tópicos e temas relacionados a mapas de tópicos e faz palestras com freqüência.

Kal é co-fundador da Networked Planet Limited, uma empresa que desenvolve ferramentas de mapas de tópicos e aplicativos baseados em mapas de tópicos para a plataforma .NET.

Graham Moore trabalha há oito anos nas áreas de gerenciamento de informações, conteúdo e conhecimento como desenvolvedor, pesquisador e consultor . Ocupou cargos de proeminência como Diretor de Tecnologia da STEP, Vice-presidente de Pesquisa e Desenvolvimento da empolis GmbH e Cientista-chefe da Ontopia AS. Foi responsável pelo desenvolvimento de produtos de gerenciamento de conhecimento, incluindo K42 Topic Map Engine, X2X Link Management Engine e e:kms Knowledge Suite. Graham é co-editor da norma XTM 1.0 XML Topic Maps e ISO13250-1 e -2 (Topic Map Data Model and Syntax), também é co-editor da TMCL (Topic Map Constraint Language).

Graham é atualmente co-fundador da Networked Planet Limited.