%% \documentclass[portuges,a4paper]{article}
%% \usepackage{babel}
%% %\usepackage[latin1]{inputenc}
%% \usepackage[utf8]{inputenc}
%% \usepackage{fancyvrb}
%% \usepackage{t1enc}
%% \usepackage{color}
%% \usepackage{aeguill}
%% \begin{document}
%% \def\citep#1{\textbf{[=#1=]}}

%% \title{}
%% \author{José João Dias de Almeida}
%% \date{\today}
%% \maketitle
%% \tableofcontents
%% \newpage



O \textsc{rena}\citep{man:rena} é um protótipo de sistema de extracção/marcação de 
entidades mencionadas construído por Edgar Alves sob supervisão de J.J. Almeida no âmbito do projecto IKF.

\subsection{Breve descrição do projecto IKF }


O projecto IKF(Information + Knowledge + Fusion)\citep{IKF1,IKF2,IKF3},
foi um projecto Eureka (E!2235) envolvendo participantes universitários e
industriais de seis países, cuja
finalidade básica é o desenvolvimento de uma infrastrutura distribuída, baseada
em ontologias para manuseamento inteligente de conhecimento -- contemplando um
ambiente documental multifonte e distribuído.


O IKF framework baseia-se num modelo de representação de conhecimento
sofisticado (baseado em ontologias, facetas, fuzzy, informação incompleta,
temporal)\citep{IKF1}, e é constituído por um conjunto de módulos envolvendo
(entre outros):
\begin{enumerate}
\item  Extractores básicos -- extracção de conhecimento a partir de documentos 
heterogéneos de modo a construir um sistema de assimilação documental:
\begin{itemize}
\item  organização de um conjunto ficheiros  modo a construir umyxa base 
             documental
\item  extracção de informação (rica) a partir desse conjunto de documentos
\item  classificação facetada, fuzzy e parcial de documentos e da informação
\item  fusão da informação extraída dos vários documentos
\end{itemize}

\item  Knowledge Renovator\citep{IKF2} -- ligada à evolução (temporal ou não) da
informação e do conhecimento.
\item  Enfermaria do Conhecimento -- ligado a sistemas legados, e a reparação de
inconsistências de razões variadas, 
\item  Navegadores -- um conjunto de navegadores sobre a base de conhecimento e 
da base documental.
\end{enumerate}


A título de exemplo de aplicação considere-se o caso da assimilação 
documental de caixas de mail: ao extrair e fundir conhecimento, pretende-se
obter informação capaz de responder a perguntas como:
\begin{itemize}
\item  quem é a pessoa F? 
\item  qual a lista dos meus amigos? quais os parceiros de X?
\item  qual o conjunto de áreas de interesses de Z
\item  que documentos são relevantes acerca de ...
\end{itemize}

Tendo em vista estes objectivos, para além das tarefas principais (as tarefas
estruturais ligadas ao projecto), foi realizado um conjunto de pequenas
tarefas/experiências explorativas, envolvendo recursos muito limitados e 
frequentemente envolvendo alunos finalistas.

É neste contexto que surge o protótipo \textsc{rena} que não fazendo directamente 
parte do projecto IKF, foi desenhado como um caso de estudo com a intenção 
de fazer extracção de conhecimento simples -- extracção de uma base de 
entidades: 
\[Rena: Ficheiro^* * BaseEnt \longrightarrow BaseDoc * BaseEnt * ...\]

\section{Descrição do \textsc{rena}}
Na sequência do enquadramento anteriormente descrito, 
o protótipo \textsc{rena} tem como intenção uma extracção tão rica
quanto possível de informação, com vista a ser usada por sistemas
de processamento, fusão de conhecimento (e em particular no projecto IKF).

À medida que a ferramenta \textsc{rena} foi sendo projectada, decidiu-se que era
importante que pudesse ser usado e pudesse abranger um conjunto 
menos restritivo de utilizações -- que pudesse ser usado em modelos semânticos
menos sofisticados (um Micro-IKF).

Dum modo resumido o \textsc{rena} é um sistema para reconhecimento de
entidades constituído por:
\begin{itemize}
\item  Uma biblioteca Perl:
\begin{enumerate}
\item  baseada num conjunto de ficheiros de \textbf{configuração} alteráveis,
\item  com funcionalidade para \textbf{extrair a lista das Entidades} a 
         partir de conjuntos de texto,
\item  ou em alternativa \textbf{marcar Entidades} num conjunto de texto
\end{enumerate}

\item  Um conjunto de scripts para fazer processamento de entidades
\end{itemize}



Como é natural, muita da capacidade de extracção depende de um conjunto de 
ficheiros e de regras -- elemento de configuração -- que descrevem 
conhecimento geral e regras de contexto usados na extracção.

Pretendeu-se desde início que esses elementos de configuração sejam
\emph{externos} ao \textsc{rena} de modo a que o utilizador os possa adaptar
à sua visão do mundo e à sua intenção concreta de utilização.

Deste modo pretendeu-se que os elementos de configuração sejam legíveis,
expressivos e compactos.

Seguidamente será feita uma descrição destes elementos de configuração.

\subsection{Ficheiros de configuração}
A configuração de base do \textsc{rena} é constituída por um conjunto de recursos:
\begin{enumerate}
\item  Ontologia de tipos de entidades -- que estabelece relações  (hierárquicas)
    entre os tipos de entidades existentes;
\item  Tabela de contextos -- com regras para deduzir qual o tipo das entidades
    com base no contexto direito;
\item  Almanaque de cultura geral -- onde se registam termos/conceitos geográficos,
    culturais, patrimoniais, cultura geral;
\item  Sistema de Nomes -- onde se guardam alguns dos nomes/apelidos mais comuns
    e regras para determinar se um Nome-Próprio se refere a pessoas;
\item  Tabela de conversão/adaptação de nomes;
\item  Tabela de contextos atributivos (em fase de construção)
\end{enumerate}


Vários destes recursos são definidos usando linguagens de domínio específico
(DSLs) construídas com a intenção de conseguir uma descrição eficaz dessa
informação.

Seguidamente vamos detalhar alguns destes recursos e  apresentar extractos 
exemplo.

\subsubsection{Ontologia de classes}

%%\textbf{\textcolor{red}{JJ, podias descrever melhor todos estes itens... há muito para dizer! Neste ponto, por exemplo, como se construiu a ontologia 2.1.1? Quantas categorias teve? Quais as dificuldades na sua criação?}}

A ontologia de classes armazena os tipos de entidades e respectivas relações.
A definição dos tipos de entidades e dos seus relacionamentos é uma actividade
delicada, sensível: corresponde a uma descrição do nosso modo de ver o Mundo.
Há zonas desta ontologia que são facilmente reutilizáveis, outras que são
dependentes do projecto concreto.

Normalmente é importante ter controlo total sobre esta ontologia pelo que
ela deve ser contituída manualmente. No entanto alguma zonas podem ser 
obtidas por aprendizagem automática.

No nossos exemplos vimos que pode haver utilidade em usar (pequenos) extractos 
de ontologias como o CDU, o thesarus da Unesco, o thesaurus da Biblioteca 
de Alexandria ou outros sistemas classificativos.

A existência deste recurso é crucial para se conseguir:
\begin{itemize}
\item   fazer inferência parcial de tipos de entidades,
\item   para facilitar a fusão de análises complementares,
\item   para se conseguir uma maior adaptabilidade da informação extraída.
\end{itemize}


Sempre que possível pretende-se que esta ontologia tenha um grão fino de 
modo a poder registar toda a informação extraída, mas ao mesmo tempo 
que permita uma posterior abstracção/síntese.

Naturalmente a dimensão e conteúdo da Ontologia de classes deverá ter em conta
a pragmática e o conteúdo e dimensão do conjunto documental em análise.
No caso concreto, utilizamos uma ontologia exemplo com cerca de 120 classes.

Segue-se um extracto da ontologia de classes (visto como uma taxonomia para
mais fácil visualização):

\begin{Verbatim}
- pessoa:
   - advogado
   - arquitecto
   - atleta:
      - futebolista
      - nadador
   - escritor:
      - poeta
   - jornalista
   - militar:
      - general
      - almirante
      - brigadeiro
      - sargento
      - tenente
      - capitão
   - músico:
      - compositor
      - pianista
      - trompetista
   - político:
      - presidente da república
      - deputado
\end{Verbatim}

Salitente-se mais uma vez que a ontologia para descrever as classes difere conforme 
a intenção e o conjunto de documentos em análise. Exempo: embora haja muitas coisas 
comuns, há uma 
enorme diferença entre o conjunto das classes referentes a um
arquivo de Biologia, a um arquivo de etnomusicologia, ou a um arquivo de Software de
PLN.

\subsubsection{Tabela de contextos}

%%\textbf{\textcolor{red}{Mesma coisa: como se construiu? Os exemplos foram derivados de textos? Foi tudo manual? }}
A tabela de contextos permite que de um modo compacto se possa definir
uma associação entre uma \textbf{expressão de contexto} esquerdo e uma
classe.

\begin{Verbatim}
  cidade (de do da)     => cidade !lctx
  freguesia (de do da)  => freguesia
  distrito (de do da)   => distrito
  concelho (de do da)   => concelho/90
  estado (de do da)     => estado
  capital               => cidade !lctx

  (Rio Oceano Lago Mar Serra Cordilheira) => $_
  Cabo (do de da)       => cabo
  Golfo (do de da)      => golfo

  (Lugar Largo Lg. Praça Rua R. Avenida) (de da do das dos)?  => lugar
  (Travessa Beco Quinta Viela Rotunda) (de da do das dos)?    => lugar

#
# Monumentos 
#
 
  (Convento Mosteiro Igreja Ig. Palácio Museu Sé) (de da)? => monumento
\end{Verbatim}
Notas:
\begin{itemize}
\item  as regras podem ter valores de confiança de modo a permitir distinguir entre
   indícios mais fortes e indícios mas fracos,
\item  a capitalização é usada para indicar se o termo de contexto esquerdo deverá
   ou não ser incluída na entidade
\item  os padrões das regras podem incluir variantes alternativas, elementos
opcionais, comentários, etc.
\end{itemize}

Embora esta tabela possa ser construída, consolidada e revista manualmente,
uma boa base de início pode ser obtida através da extracção das bigramas de
palavras do contexto direito e do inicio de entidade (das entidades antes ou
depois de  classificadas) -- podendo ser usadas técnicas de bootstraping 
habituais em situações idênticas\footnote{No
estado actual do \textsc{rena}, há apenas um esqueleto uma ferramentas de 
ajuda à construção dessa tabela segundo o método referido.}.

Muitas regras são gerais; no entanto no caso geral esta tabela depende do 
problema concreto.



\subsubsection{Almanaque de cultura geral}
Conforme atrás se referiu, o Almanaque de cultura geral pretende
guardar alguma informação de cultura geral de índole diversa.

Presentemente este Almanaque tem por base informação criada no âmbito de
projecto \t2o\citep{elpub06-t2o,lrec06}, e a informação associada a cada entidade é 
por vezes rica (ainda que heterogénea): além duma classe de base, pretende-se
armazenar um conjunto de atributos e ligações tão rico quanto possível.

Simplificadamente o Almanaque corresponde a uma vista sobre a 
projecção de uma ontologia \t2o seleccionando-se os termos
referentes a:
\begin{itemize}
\item  geografia
\item  personagens famosas
\item  eventos
\item  ...
\end{itemize}


No seguinte exemplo mostra-se um extracto da informação existente no
Almanaque associada ao \textbf{Rio Douro}:

\begin{Verbatim}
Rio Douro =
 rio Douro
        IOF =>  rio
        AFLUENTES =>    rio Mau,
                rio Sousa,
                rio Varosa,
                rio Tâmega,
                rio Pinhão,
                ....
                rio Torto,
                rio Távora,
                rio Esla,
                rio Tua
        COMPRIMENTO =>  927
        FOZ =>  Porto
        IN =>   Portugal,
                Espanha
        NASCE =>        serra do Urbião
        PASSA_EM =>     barragem do Pocinho,
                barragem de Miranda,
                barragem de Crestuma,
                Miranda do Douro,
                barragem do Carrapatelo,
                Régua,
                barragem da Bemposta
\end{Verbatim}

Como se nota há uma intenção de dispor de um conjunto de dados de
base rico e estruturado que permita processamento posterior (interactivo
ou não).

\subsubsection{Sistema de tratamento de nomes}

A intenção ligada ao 
\textbf{sistema de tratatamento de nomes}
é permitir dispor de dados para determinar se certos identificadores
constituem (ou não) prováveis nomes de pessoas (quando não houver 
fortes indícios noutro sentido).

\begin{Verbatim}
26.62287        Maria   nome
13.70273        Ana     nome
6.85846         José    nome
5.16030         Silva   apelido
4.90977         António nome
3.95357         Carla   nome
3.51606         Manuel  nome
3.50263         João    nome
...
0.02148         Dinis   misto
\end{Verbatim}

De um modo simplificado, guarda-se um tabela que indica a taxa de
ocorrência (por milhão de palavras) de determinada palavra, indicando
ainda se o seu uso é preferencialmente nome, apelido ou misto.

Esta lista tem por base uma lista de 150k nomes completos, de várias
proveniências.

\subsubsection{Tabela de conversão/adaptação de nomes}
Dado que há necessidade de poder usar ontologias de classes e tabelas de
contextos adaptadas a cada projecto concreto, temos necessidade de criar mecanismos
para conversão de classes.

Esta tabela pretende criar um grau de indirecção de modo a permitir
uma mais fácil alteração da estrutura da ontologia de classes.

A finalidade principal desta tabela é criar alguma independência entra
a ontologia de classes, o Almanaque e a tabela de contextos.

%%\textbf{\textcolor{red}{Explicar o que é, dar um exemplo concreto tal como nas restantes subsecções}}

\subsubsection{Tabela de contextos atributivos}

%%\textbf{\textcolor{red}{Apesar de estar em fase de implementação, podes referir como é que vocês constroem isto, ou pretendem fazer: é inferido manualmente?}}

Este recurso está ainda em fase implementação.

Considere-se o seguinte extracto exemplo:
\begin{Verbatim}
 a atleta portuguesa A :: atleta(A), nacionalidade(A,portuguesa)
 X , no norte de Y     :: geo(X), geo(Y), norte(X,Y)
 o francês Z           :: pessoa(Z), nacionalidade(Z,francês)
\end{Verbatim}

Notas:
\begin{itemize}
\item  linha 1: quando for encontrada uma ocorrência como \textbf{...a atleta
portuguesa Rosa Mota ...} é feita a inferência de que Rosa Mota é uma
atleta (e portanto uma pessoa, etc), e que o atributo nacionalidade da
entidade em causa é preenchido com o valor \textbf{portuguesa}.
\end{itemize}


A intenção da tabela de contextos atributivos é, para além de 
eventualmente inferir classes, ajudar a inferir mais atributos, 
factos  e informações acerca das entidades -- informação mais rica.

Esta tabela é crucial para a riqueza da informação extraída. 
Até ao momento, ela tem sido construída manualmente, no entanto há planos 
para construção de ferramentas para
propor regras e extrair pistas a partir de textos anotados.

\subsection{\textsc{rena}: estrutura interna}
Do ponto de vista algorítmico, o \textsc{rena}:
\begin{enumerate}
\item  começa por procurar entidades e construir uma sequência de textos simples
e entidades: \( (texto \times entidade)^* \)
\item  seguidamente esse objecto é processado por uma série de filtros
 com assinatura:
\[ f: (texto \times entidade)^* \rightarrow (texto \times entidade)^* \]
  Estes filtros vão processar os pares texto-entidades, enriquecendo
informação, alterando fronteiras, unindo zonas, com base nos recursos de
configuração atrás referidos e utilizando ferramentas internas ou
externas (ex, analisador morfológico jspell \citep{jspell2002,Almeida94c}).
\item  no final, de acordo com a saída pretendida, é criado:
\begin{itemize}
\item  um texto com as entidades anotadas
\item  um resumo das entidades presentes
\item  ...
\end{itemize}

\end{enumerate}


Os filtros acima referidos podem ser desactivados e fazem tarefas como:
\begin{itemize}
\item  tratamento de entidades com elementos de uma única letra,
\item  tratamento de aspas ligado às entidades
\item  remoção de entidades entre aspas -- este  filtro só deverá ser usado se 
     se pretender ignorar este tipo de ocorrências.
\item  tratamento de entidades com traços interiores (exemplo Benfica-Sporting)
\item  tratamento de entidades em início de frase
\item  enriquecimento por análise de regras de contexto
\item  enriquecimento por análise de gazetteer de nomes
\item  enriquecimento por análise de Almanaque
\item  tratamento de acrónimos
\item  reconhecimento e unificação de entidades iguais (ou abreviadas) e
   criação de atributos de ligação entre as várias ocorrências da mesma
     entidade;
\item  geração do formato final pretendido:
\begin{itemize}
\item   xml -- para escrever em formato \textit{XML}, uma versão
do texto original onde são anotadas todas as referências a entidades
encontradas.
\item   Unified\_yaml -- 
        Este filtro escreve uma representação, no formato 
        \textit{YAML}\citep{yamlspec,yamlcookbook}, de
todas as entidades com alguma referência no texto, bem como todas as
classificações atribuídas.
\end{itemize}

\end{itemize}


\section{Participação no HAREM}
A participação no HAREM foi muito importante e produtiva para nós
já que:
\begin{itemize}
\item  envolveu discutir e trocar impressões com os outros participantes e
    com a organização
\item  envolveu lidar com um problema para o qual o \textsc{rena} não tinha sido pensado,
\item  levantou uma série de questões que nunca nos tinham ocorrido referente
à necessidade de criação de camadas de adaptação de notações e de adaptação de estruturas
classificativas.

%%\textbf{\textcolor{red}{estes dois pontos são muito vagos...parecem-nos aliás apenas repetir os dois anteriores
%%Nuno:  JJ, tens aqui uma oportunidade de meter parágrafos bem interessantes aqui, pois é interessante ver como um sistema participante gria um sistema REM segundo uma certa visão, e depois depara-se com a visão do HAREM... seriam três, quatro parágrafos bem 'suculentos'. As conclusões também podiam benefiiuar dessa discussão}}

\end{itemize}


Há no entanto alguma diferença entre o tipo de avaliação que pretendíamos (mais
ligada a um uso de extracção de informação enciclopédica) e a avaliação HAREM.


Os resultados finais ficaram aquém do que seria possível por várias
razões:
\begin{itemize}
\item  o autor do \textsc{rena} (Edgar Alves) não ter participado (por ter 
já deixado a universidade e estar ocupado com os seus afazeres 
profissionais)
\item  haver decisões do \textsc{rena} que não seguem as propostas HAREM 
e das quais não quisemos prescindir,
\item  Com o pouco tempo que foi possível dedicar, termos optado por
melhorar alguns módulos que não sendo os mais importantes para a 
avaliação HAREM, são cruciais para o \textsc{rena}.
\end{itemize}


Genericamente a marcação de entidades foi bem conseguida
apesar de termos optado por não marcar valores numéricos 
em geral por nos parecer menos interessante para o \textsc{rena}.

Os maiores problemas resultaram de uma diferente filosofia no
que diz respeito às classes -- diferente filosofia semântica.
Enquanto que o HAREM pretende marcar a ocorrência específica em 
contexto específico, o \textsc{rena} está menos preocupado com a ocorrência
concreta mas com a entidade referida; está mais preocupado com a 
extracção de informação rica de cariz enciclopédico.

Considere-se o seguinte exemplo concreto:
\begin{Verbatim}
...os diários "<OBRA TIPO="PRODUTO" >Jornal Tribuna de Macau</OBRA>" 
<OBRA TIPO="PRODUTO">Macau Hoje</OBRA> e ...
\end{Verbatim}

De acordo com a nossa intenção de extracção de informação enciclopédica, afirmar 
que o \emph{Jornal Tribuna de
Macau} é um \textbf{Obra:Produto} seria completamente inaceitável: a
resposta útil para o \textsc{rena} (independentemente de o termos conseguido
extrair) é \textbf{Jornal} ou \textbf{Jornal diário}.

Do mesmo modo demos preferência a \textbf{monumentos} em relação aos
\textbf{Locais:Alargados} ou às \textbf{Obra:Arte}.\\

A participação semântica do \textsc{rena} foi feito através de:
\begin{enumerate}
\item  extrair a informação e usar apenas a classificação geral de acordo com a 
ontologia \textsc{rena}
\item  traduzir (de acordo com uma tabela de tradução escrita manualmente) cada
classificador \textsc{rena} num par entidade:tipo do HAREM
\end{enumerate}


Esta abordagem também introduziu erros adicionais (e alguma classes como monumento
acabaram por não encontrar um classificador natural na estrutura classificativa
HAREM).\\

Optamos por não fazer marcação morfológica por não nos parecer tão relevante para
a nossa ferramenta específica e para não dispersar (e congratulamo-nos
com a versatilidade do sistema HAREM de poder aceitar marcações parciais).

No próxima secção apresentamos mais alguns exemplos e situações em que
os modelos HAREM e \textsc{rena} divergiram.


%%\textbf{\textcolor{red}{Esta secção devia passar para antes das Conclusões, e deixar de ser um anexo.}}


\section{\label{futuro} Subsídio para a discussão sobre futuras edições }

A organização e planeamento do HAREM foi a meu ver muito boa. No entanto
e tendo em conta futuras organizações vou enunciar algumas coisas
que me pareciam ser vantajosas.

Em resumo as propostas para futuras versões são:
\begin{enumerate}
\item  uso de documentos seguindo (totalmente) a norma XML
\item  uso claro e extensível de metadados nas colecções
       \[coleccao = (MetaData \times Texto )^* \]
\item  migração de taxonomia 2 níveis para uma ontologia de classes multi-nível
\item  uso de etiquetagem mais versátil.
\end{enumerate}


\subsection{Uso de documentos seguindo XML}
A migração para documentos XML, torna mais fácil tirar
partido de um conjunto de ferramentas no sentido de:
\begin{itemize}
\item  permitir verificar se os documentos (colecções e submissões) são
       bem-formados e se são válidos
\item  ser claro e definido qual o sistema de encoding usado
\item  poder obter mais facilmente uma variedade de vistas 
 (pritty-printers), resumos, e reordenações dos documentos, de modo a se adaptar 
 a diversas finalidades. (Usando CSS, XSL, etc)
\item  ser trivial o cálculo de um conjunto de estatísticas e pesquisas (Usando XPath e afins)
\end{itemize}


\subsection{Uso claro e expansível de metadados nas colecções}
A existência de metadados nas colecções foi algo que a organização
teve em conta, Existe um elemento \texttt{DOC}, com metadados variante linguística e
género\footnote{Com os valores \emph{CorreioElectrónico, Entrevista, Expositivo, Jornalístico, Literário, Político,
Técnico, Web.}}.

\begin{Verbatim}
 <DOC>
   <DOCID>HAREM-871-07800</DOCID>
   <GENERO>Web</GENERO>
   <ORIGEM>PT</ORIGEM>
 ...
\end{Verbatim}

Por um lado parece-me que os valores do atributo género cobrem mais que uma faceta:
um documento \emph{político} (conteúdo temático) poderá ser também uma \emph{entrevista}, ou
estar disponível (suporte) em \emph{Web, CorreioElectrónico}. Ou seja, 
seria útil múltiplas ocorrências de géneros, ou separar esta informação 
em mais que um campos.

Por outro lado gostaria de ver um elemento Meta que agrupasse toda a metadata 
do documento de modo a permitir que possa haver mais fácil enriquecimento (por
parte do HAREM ou de outro qualquer uso futuro).

% A título de exemplo parece-me que faria sentido metadados referente a:
%   . tipo de documento (artigo \LaTeX, página html, email, ...)
%   . domínio temático
%   . data
%   . proveniência
%   #

\subsection{Questões ligados à estrutura classificativa usada}
Cada entidade marcada está a ser classificada "semanticamente".

% ===Um pouco de história

Originalmente o MUC propôs um sistema classificativo a um nível e incluindo
3 ou 4 classes (Pessoa, Instituição, Entidade geográfica, ...).
Apesar de alguns problemas conhecidos,
esta proposta faz perfeitamente sentido, e permitiu a realização de
avaliações conjuntas.

O HAREM propôs subir a fasquia para uma categorização
a 2 níveis -- taxonomia a 2 níveis. A meu ver essa decisão foi
necessária e acertada.\footnote{
Genericamente subir a fasquia é bom quando houver pelo menos um
atleta que a transponha...}. Havendo uma taxonomia a 2 níveis, há
naturalmente a hipótese de participações parciais:
\begin{itemize}
\item  nível 0 --> marcar apenas as entidades
\item  nível 1 --> apresentar apenas as classificações do primeiro nível
\item  nível 2 --> apresentar a classificação completa.
\item  ou ainda escolher uma subárvore da taxonomia em causa.
\end{itemize}


Por outro lado, foi  construída uma função
de conversão \[harem2muc : Charem \longrightarrow Cmuc\]  que mapeia
classificações HAREM em classificações MUC. -- tornando possível a comparações
de resultados (medidas de acerto) entre as duas competições.
Esta função de mapeamento entre os dois sistemas para a maioria dos casos
é simples e natural, havendo no entanto zonas da estrutura HAREM que são
difíceis de mapear em MUC (o que não surpreende nem impede a leitura dos valores
após conversão).

Dum modo semelhante parece-me que há zonas da taxonomia HAREM que são
pouco naturais e claras -- vistas pelo prisma de representação de conhecimento.

Constatou-se naturalmente dificuldades em arranjar consenso entre os
participantes em relação ao referido sistema de classificação HAREM, o que é
natural e habitual nestas actividades, e que me parece não ter constituído
obstáculo importante ao funcionamento.

Genericamente a marcação combinada tem o seguinte aspecto:
\begin{Verbatim}
  <Nivel1  tipo="Nivel2">Entidade encontrada</Nivel1>
\end{Verbatim}

No que diz respeito à estrutura classificativa, os problemas com que deparamos são:
\begin{enumerate}
\item  apesar de existir uma etiqueta de alternativa  (\verb!<ALT></ALT>!) para
descrever alternativas de que sequências de palavras compõem a entidade (ambiguidade
textual), uma notação (\verb!|!) para ambiguidade das
classes semântica e ainda uma classe especial \verb!outra! para situações \emph{duvidosas}, 
não vejo claramente como descrever ao nível da marcação:
\begin{itemize}
\item  \textbf{ignorância total} (ex: \emph{o X é interessante} -- não sei nada acerca
de X). Um humano normalmente saberá classificar uma ocorrência mas é frequente um
ferramenta não o saber; nessa situação pretendemos anotar essa ignorância.
\item   dúvida (ex: \emph{o Porto é imprevisível}: ou é uma cidade ou um clube de
futebol mas não as duas ao mesmo tempo -- só consegui concluir alguma informação parcial),


\item   classificação múltipla (\emph{na Biblioteca da Universidade de Coimbra encontramos o espírito barroco} -- acho válidas duas ou mais classificações Obra de
    arte, Local Biblioteca, ...)
\end{itemize}

ou seja:
\begin{Verbatim}
  <nivel1 tipo="não faço ideia">e1</nivel1>
  <nivel1 tipo="das duas uma:A ou B mas tenho dúvidas qual">e1<nivel1>
  <nivel1 tipo="tanto A como B são tipos de">e1<nivel1>
\end{Verbatim}

Naturalmente o nível de ambiguidades/ignorâncias aparece mais na resposta 
dos sistemas do que na resposta de humanos.

\item  haver situações (ao fazer a "formatação" a dois níveis) em que
    certas sub-árvores são facetas (quase independentes)
    levando a que faça sentido duas classificações, e que por vezes a solução
    oficial "perca" certas facetas e aspectos cruciais à caracterização da
    entidade em causa.
 \begin{quotation}Considere-se o seguinte exemplo da colecção dourada
\begin{Verbatim}
 <LOCAL|OBRA TIPO="ALARGADO|ARTE">Biblioteca Pública</LOCAL|OBRA>
\end{Verbatim}
 A referida biblioteca é um lugar, um edifício ou semelhante mas
simultaneamente é património artístico, (é uma obra de arte).
De certo modo, ser ou não obra de arte é uma faceta que poderemos querer
aplicar a edifícios, livros, cidades e outra classes.
Portanto constitui uma informação que deveria poder coexistir com a informação da
classe a que se refere. Ou seja aquela biblioteca é simultaneamente um edifício 
e uma obra de arte.
  \end{quotation}

\item  genericamente a existência de herança múltipla complica certas zonas
      da estrutura classificativas. 
     \begin{quotation}
Considere-se o seguinte exemplo teórico. Se a minha maneira de ver o mundo
considerar que:
\begin{Verbatim}
   palácio    é um subcampo   obras de arte
   palácio    é um subcampo   edifícios
\end{Verbatim}
(ou seja palácio tem dois pais, ou tem herança múltipla dessas duas classes)
uma marcação em taxonomia a dois níveis (e já agora usando uma notação semelhante à do
HAREM) tenderá a ver uma ambibuidade artifical entre
\begin{Verbatim}
   <ObraDeArte tipo="palácio">...
   <Edifício   tipo="palácio">...
\end{Verbatim}
Em situações como esta o uso de \textbf{palácio} (sem obrigação de 
escolher qual dos pais) tenderia a simplicar as coisas.
     \end{quotation}


\item  por vezes o enquadramento das ferramentas concorrentes força estruturas
      classificativas diferentes das usadas  e ligeiramente "antagónicas".
 Isto é apenas uma constatação que complica a participação e para a qual não há uma 
solução óbvia mas que ainda assim descrevemos:

%% \textbf{\textcolor{red}{Este ponto deve ser revisto, porque a razão para serem consideradas classificações diferentes não tem nada a ver com os concorrentes!.}}
     \begin{quotation}
     Considere-se o seguinte par de exemplos da colecção dourada:
\begin{Verbatim}
 Visite o <OBRA TIPO="PRODUTO">DataGrama Zero</OBRA> a Revista Eletronica
 ...

 A revista foi denominada <ABSTRACCAO TIPO="NOME">Medicina e Cultura</ABSTRACCAO>
 ...
\end{Verbatim}
Independentemente do contexto linguístico em que estas entidades possam estar a
ser usadas,
dum ponto de vista de representação de conhecimento pretende-se 
tirar partido de que esta duas revistas têm muito em
comum (classes idênticas ou aparentadas) e será completamente inaceitável 
%% \textbf{\textcolor{red}{inaceitável não será um pouco forte demais?}} 
ignorar/esquecer que \emph{Medicina e Cultura} é uma \emph{revistas}.
     \end{quotation}
\end{enumerate}



\subsection*{A granularidade e capacidade distintiva}
Considere-se a questão ligada com os conceitos Portugal, país, entidade geográfica, etc:

O seguinte conjunto de relações binárias pode ser usado para descrever (algumas
das) propriedades do conceito:

\begin{Verbatim}
   Portugal IOF  país
   país     ISA  entidade geográfica
   país     ISA  instituição administrativa
   país     ISA  povo
   ...
\end{Verbatim}

Numa situação como a do IKF/\textsc{rena} não dispomos de informação suficiente para
resolver devidamente essa questão: optámos por baixar a fasquia: ter uma
classificação que falhe 40\% dos casos é pior do que dizer que é simplesmente
um país.

Na visão IKF/\textsc{rena} a nossa intenção corresponde a ir decorando a árvore de
conhecimento com todos os atributos que conseguirmos obter (obviamente
trata-se de uma finalidade específica nossa), ou seja pretendemos juntar
em "Portugal" os atributos ligados a país nas suas várias acepções e
usos (presidente da república, língua, rios, área, etc).

Esse tipo de junção processamento de atributos, heranças, etc, cria restrições
acerca do tipo de árvores classificativas a usar:
 a relação subclasse (nível1 -- nível2 da estrutura HAREM) passa
a ter maiores responsabilidades...

\subsection{
  %\textbf{\textcolor{red}{
            Sugestão para futuras edições
  %         }}
}

Em resumo, para futuras edições propunha:
\begin{itemize}
\item   Etiquetagem mais prática:
\begin{itemize}
\item  uma única tag Entidade \verb!<ent ...>...</ent>!
\item  um atributo \emph{tipo} \verb!<ent t="país">...</ent>!
\item  com notação clara para alternativas \verb!<ent t="t1|t2"> ...!
\item  com notação clara para multiclassificação \verb!<ent t="t1;t2"> ...!
\item  para informação parcial = escolher um nó mais acima na árvore classificativa
       (caso extremo = topo = entidade)
\item  um atributo de unificação para permitir ligar referências à mesma entidade
\end{itemize}

\item  Ontologia multi-nível de classes, com herança múltipla,

\item  Identificadores de classe mais claros e únicos -- a questão da clareza é crucial 
\footnote{No geral, em teoria da classificação há a recomendação de que cada classificador
deverá, sempre que possível, ter autonomamente uma leitura clara.} 
para o contexto de extracção de informação
onde o \textsc{rena} se encaixa -- (dizer 
que \emph{Palácio de Vila Flor} é um \emph{LOCAL:ALARGADO} é inaceitável do
ponto de vista de extracção de informação enciclopédica \footnote{Como dissemos,
do nosso ponto de vista, palácio, monumento, etc, seria preferível. Classicações como 
Local, localidade, edificação, são também claras; \emph{Local:alargado} por si só é de leitura
pouco clara e parece-me significar algo como \emph{local que não se encaixa nas outras subcategorias}.}. 
%% \textbf{\textcolor{red}{Indicar qual a classificação aceitável...}}


\end{itemize}

\section{Conclusões e trabalho futuro}
Foi muito positivo a participação no HAREM embora por questões temporais
não tenha sido possível tirar partido de uma série de iniciativas.

Seguiu-se uma abordagem que não visava maximizar o resultado final da
avaliação mas antes o tentar ajudar à evolução do \textsc{rena} de acordo com 
os nossos objectivos imediatos (que por vezes não coincidiram com os do HAREM).

Apesar das evoluções conseguidas e o estado actual do \textsc{rena} é de
software protótipo.\\


Ao nível do trabalho futuro, há genericamente o objectivo de melhorar:
\begin{itemize}
\item  melhorar as regras de inferência e unificação e resumo
\item  criar um processador estrutural
\item  melhorar o sistema de tratamento de nomes incluindo também dados estrangeiros
\item  documentar melhor o interface de biblioteca Perl, nomeadamente
   os processadores de ordem superior actuais
\begin{Verbatim}
  forent($texto){ .... }
\end{Verbatim}
\end{itemize}





%% \end{document}
