O uso correto do idioma que fala é importante para o cidadão em suas atividades profissionais, onde termos específicos variam de acordo com a atividade profissional desempenhada.
%
Por exemplo, pessoas que exerçam atividades no ramo jurídico utilizam termos específicos do direito no seu dia a dia profissional, tais quais \textit{habeas corpus}, abroquelar, cártula chéquica, areópago, fulcro e estipêndo funcional; no ramo médico, os termos poderiam ser incisão, febrífugo, benigno, ejunorrafia ou abdução.
%
De modo semelhante, o ensino de uma língua estrangeira depende do aprendizado de novas palavras com novos significados.
%
A aquisição de um repertório do idioma ou do dialeto a ser utilizado é necessário para o correto uso deste no dia-a-dia, entendendo e fazendo ser entendido por seus interlocutores.
Para auxiliar a aprendizagem de uma língua estrangeira \cite{anthony2013critical, oliveira2009linguistica}\apud{granger1998tag}{sardinha2000linguistica} ou do idioma para fins específicos \cite{oliveira2009linguistica} como no cotidiano profissional, a análise de corpus de textos é uma técnica que pode ser utilizada.
%
Segundo \citeauthoronline{sardinha2000linguistica}, um desses trabalhos do século XX foi o de Thorndike, publicado em 1921, que identificou as palavras mais frequentes de língua inglesa e \aspas{[...] impulsionou mudanças no ensino de língua materna e estrangeira, tanto nos Estados Unidos quanto na Europa [...]} (p. 236), onde \aspas{durante boa parte do século XX [...] muitos pesquisadores [...] se dedicaram à descrição da linguagem por meio de corpora, [...] [que] eram coletados, mantidos e analisados manualmente [...]} (p. 235).
%
Entretanto, no século XX, a velocidade e os custos de propagação da informação ainda eram elevados.
Com o desenvolvimento tecnológico das telecomunicações, os custos de acesso à internet reduziram, a largura de banda aumentou e a rede ganhou mais usuários.
%
De acordo com uma pesquisa do \citet{cetic2016pesquisa}, 51\% do total de domicílios possuem acesso à internet, 86\% dos alunos acessaram a internet ao menos uma vez no último trimestre à pesquisa e 95\% dos professores possuíam acesso à internet em casa.
%
Isso vem gerando uma crescente pervasividade da internet na vida das pessoas.
%
Por conta disso, a web é uma plataforma que possui o potencial de atingir um grande número de pessoas em território nacional.
%Com base nesse contexto, este trabalho propõe a criação de um sistema na nuvem, ou seja, na internet, para pesquisa e análise de coleções de textos com exemplos significativos de uso da língua portuguesa.
%
%Esta ferramenta será útil para auxiliar o estudo da língua como realmente é usada.
Atualmente, existem ferramentas voltadas ao usuário final capazes de processar corpus de textos, dentre elas podemos destacar o Word Smith, o Unitex/GramLab, o Sketch Engine e o Palavras. Destes, apenas o segundo é livre e apenas o terceiro possui uma interface web; sendo nenhuma delas livre e web simultaneamente, como pode ser observado na tabela \ref{tab:compplnres}. Dentre as ferramentas que processam a língua portuguesa, não há nenhuma plataforma que seja ao mesmo tempo livre e cuja sua interface seja web.
Desenvolver uma plataforma web livre para marcação e busca morfossintática em corpus de textos visando ampliar as funcionalidades em relação a softwares similares existentes enquanto se mantém amigável ao usuário.
\subsection{Específicos}
\label{obj:esp}
\begin{itemize}
\item Analisar comparativamente os recursos das ferramentas WordSmith, CorpusEye, COCA Online Corpus, Unitex/GramLab e Sketch Engine;
\item Desenvolver um módulo extrator de lista de palavras;
\item Desenvolver um módulo extrator de palavras-chave;
\item Desenvolver um módulo concordanciador, que suporte busca por funções sintagmáticas e morfológicas;
\item Integrar os módulos desenvolvidos numa plataforma web.
No capítulo 2 apresentaremos um histórico, os principais conceitos e alguns trabalhos relevantes da área de processamento da linguagem natural. No capítulo 3 apresentaremos os materiais e os métodos utilizados para desenvolver este trabalho, bem como as decisões relevantes ao desenvolvimento do projeto. No capítulo 4 apresentaremos e discutiremos os resultados obtidos. No capítulo 5 apresentaremos a conclusão, as contribuições deste trabalho e temas para trabalhos futuros.
Neste capítulo, são apresentados os conceitos relativos a processamento de linguagem natural, numa revisão histórica da área e seu progresso, e o atual estado da arte com seus requisitos para o progresso.
% Revisão da literatura::Revisão histórica da área
% Revisão da literatura::Progresso na área
%
A linguística de corpus, segundo \citet{sardinha2000linguistica}, já existe desde a Antiguidade, citando o Corpus Helenístico de Alexandre, O Grande e os corpora de citações da bíblia produzidos durante a Antiguidade e a Idade Média, sendo seus processos de obtenção e análise tarefas que não dependem dum computador para serem executadas. Um corpus é uma \aspas{coletânea de textos [...] compilados segundo critérios específicos para o estudo a que se propõem}\cite[p. 358]{tagnin2010glossario}, e estes buscam representar a linguagem \cite{cambria2014jumping}, ou uma variante desta \cite{sardinha2000linguistica}, podendo ser usada como forma de obtenção de informações nas mensagens nela codificados. \citet{sardinha2000linguistica} evidencia que \aspas{durante boa parte do século XX [...] os corpora [...] eram coletados, mantidos e analisados manualmente [...]} (p. 235), o que mudou com a invenção do computador, que se popularizou na década de 1960.
Ainda enquanto trabalho manual, podemos citar o trabalho de contagem de 4,5 milhões de palavras realizada manualmente por Thorndike \cite{sardinha2000linguistica}, cujo produto foi uma lista de frequência de palavras. Uma das possíveis aplicações da linguística é extrair palavras-chave, esta que \citet{tagnin2010glossario} define como sendo \aspas{resultados da comparação entre o corpus de estudo e um corpus de referência} (p. 359), sendo um processo baseado em contagem, o qual \aspas{elimina palavras com frequência relativa similar nos dois corpora de modo que restem as palavras cuja frequência é estatisticamente significativa} (p. 359), podendo as frequências ter sido calculadas computacionalmente ou manualmente. \citet{cambria2014jumping} ressaltam que processos de obtenção automática de palavras-chave buscam apenas na \aspas{superfície} do texto, exemplificando que um texto sobre cães pode apenas mencionar as diversas raças, não sendo recuperado caso indexado por suas palavras-chave.
Em fevereiro de 1957 foi publicada a obra \textit{Syntactic Structures} de Noam Chomsky, que, de acordo com \citet{sardinha2000linguistica}, mudou o paradigma de abordagem na linguística, saindo o empirismo e entrando o racionalismo; ou seja, a análise de volumosos corpora de textos, que é sujeito à inúmeras falhas, deu lugar a \aspas{[...] teorias racionalistas da linguagem [...], notadamente a lingüística gerativa. [...]}\cite[pp. 236-237]{sardinha2000linguistica}. Esta abordagem se popularizou principalmente no início da década de 1960, quando o computador se popularizou.
Com a popularização do computador, representar computacionalmente a linguagem foi necessária, e uma abordagem de representação computacional da linguagem é modela-la como uma gramática gerativa de Chomsky \cite{chaves2014sistema, cambria2014jumping}. Um dos desafios encontrados foi resolver ambiguidades, que foi solucionado através Autômatos finitos com transições ponderadas visam resolver tal problema ao representar cada palavra em sua possível função atribuindo pesos nas transições, formando assim um modelo probabilístico para etiquetagem do texto \cite{vieira2001linguistica, thiele2015desambiguaccao}; entretanto, nem toda palavra representa uma entidade por si só. Entidades Nomeadas são referências de mais de uma palavra que referenciam uma única entidade \apud[]{nadeau2007survey}{bruckschen2010reconhecimento}. Segundo \citet{aranha2006tecnologia}, o reconhecimento destas no texto se dá através de perguntas como \aspas{Quem, Quando, Como, Onde} (p. 6). \citet{bruckschen2010reconhecimento} menciona referências a datas, números e unidades monetárias como itens do texto comumente inclusas como entidades nomeadas, sendo que \citet{aranha2006tecnologia} também inclui siglas. A união da identificação prévia de entidades nomeadas à representação das sentenças como autômatos foi uma abordagem de solução deste problema.
O atual estado da arte para etiquetadores morfossintáticos da língua portuguesa, por \citet{silva2014indexacao}, é o PALAVRAS, de \citeauthoronline{bick2000parsing}. É uma gramática de restrições que, carregada no software CG-3, realiza o etiquetamento automático de textos. Possui uma taxa de acerto de 94\% em relação aos seus próprios resultados, e 86,5\% se comparado a uma extração manual \cite[p. 169]{silva2014indexacao}. O etiquetador CG-3 é mantido como software livre e distribuído pelo projeto de pesquisa e desenvolvimento \textit{Visual Interactive Syntax Learning} (VISL) do Instituto de Línguas e Comunicação (ISK) da Universidade do Sul da Dinamarca (SDU), já a gramática é paga.
Dentre os etiquetadores morfossintáticos gratuitos, o estado da arte, de acordo com \citet{silva2014indexacao}, é o LX-Parser. Possui uma taxa de acerto de 75\% em relação aos seus próprios resultados, e 97,5\% se comparado a uma extração manual \cite[p. 170]{silva2014indexacao}. Apesar de gratuito, sua licença é de redação própria \cite{lxparserlicense} e em sua cláusula 6 proíbe a distribuição e comercialização de produtos ou serviçõs derivados, já em sua cláusula 7, veta a disponibilização da ferramenta por outros meios e a cláusula 9 veta o acesso de outros \textit{sites} à ferramenta; portanto, a licença da ferramenta permite apenas a descarga e execução local da mesma.
Outro projeto é o Unitex/GramLab, onde sua versão em português brasileiro foi primeiramente apresentada por \citeauthoronline{muniz2005unitex} em \citeyear{muniz2005unitex}. Consiste de uma interface gráfica em Java que faz chamadas a bibliotecas e utilitários de linha de comando compilados de códigos em C++. A licença do software é a \textit{Lesser General Public License} versão 2.1 \cite{lgplv21}, já seus recursos linguísticos estão sob a \textit{Lesser General Public License For Linguistic Resources}\cite{lgpllr}, ambas licenças livres. O pacote redistribuível padrão já fornece ferramentas e dados complementares necessários para etiquetar um texto de entrada arbitrário. Outros recursos da mesma plataforma são busca por autômato, busca por expressão regular, representação do texto como autômato, inferência de entidades nomeadas e aplicação de transdutores \cite{paumier2016user}.
De acordo com \apudonline[p. 49]{biber1995dimensions}{oliveira2009linguistica}, \aspas{um corpus linguístico de base computacional corresponde a coleções de textos que ocorrem naturalmente na língua, organizadas sistematicamente para representar áreas de uso da língua, e das quais podemos extrair novas informações}. Tal organização pode seguir critérios diversos, mas é esperado que estes estejam anotados no texto. \citet{aluisio2006constroi} menciona a ferramenta \textit{Lácio-Ref}, a qual visa fornecer metadados para os textos, para estes serem futuramente processados. Tais metadados são: título, subtítulo, língua, fonte, editor, local de publicação, comentários, nome do(s) autor(es), sexo do(s) autor(es), gênero e tipo textual \cite{aluisio2006constroi}. Outra ferramenta é o \textit{AntCorGen}, de \citet{anthony2017antcorgen}, a qual visa manter organizados corpus de texto através de categorias, subcategorias e seus metadados, tais quais: título, autor, seção \aspas{resumo}, seção \aspas{introdução}, seção \aspas{materiais e métodos}, seção \aspas{resultados e discussão}, seção \aspas{conclusões}, seção \aspas{referências}, afiliações do autor e legendas de figuras e tabelas. Os metadados mencionados ajudam a descrever o contexto ao qual texto está inserido.
\subsection{Indexação automática por meio da extração e seleção de sintagmas nominais em textos em língua portuguesa}
Diferentemente da língua inglesa, segundo \citet{silva2014indexacao} (p. 155) \aspas{pesquisas [...] em língua portuguesa ainda não atingiram um grau de amadurecimento elevado [...] pois elas não alcançam uma taxa de precisão elevada para todos os tipos de corpus.} Dada a escassez de ferramentas eficazes para processamento da língua portuguesa, o referido autor comparou três etiquetadores morfossintáticos (OGMA, PALAVRAS e LX-PARSER), e constatou que cada um possui suas peculiaridades de modo a existir situações onde alguns se destacam e outras onde apresentam dificuldades. Tais ferrametas comparadas eram as principais ferramentas existentes até 2014.
A língua portuguesa possui sintagmas nominais, verbais, adjetivais e preposicionados \cite{gagnon2000processamento}. Os verbais podem ser analisados conforme proposto por \citet{chaves2014sistema}, onde propõem a utilização do \aspas{[...] formalismo da gramática livre de contexto [...], comumente utilizado na linguística computacional para a implementação de protótipos capazes de modelar a estrutura sintagmática de uma língua natural}, sendo definido pelos próprios autores como \aspas{um protótipo com resultados interessantes} que carece na quantidade de estruturas cobertas pela gramática definida e na necessidade de melhorar a taxa de acerto na etiquetagem dos textos - sem citar valores numéricos. Tal trabalho fornece uma ferramenta para obtenção automática da análise sintagmática, mas que necessita de aprimoramentos e quantificações numéricas quanto sua eficácia.
Com uma taxa de acerto na ordem de 99\% para morfologia e entre 96\% e 97\% para sintaxe para processamento de texto livre, uma das adaptações necessárias por Bick no modelo da língua inglesa para operar para a língua portuguesa foi \cite[p. 438]{bick2000parsing} a \aspas{introdução de marcadores de dependência a nível de cláusula [...] e a introdução de funções de marcação de subcláusula para subcláusulas finitas e não-finitas}, onde algumas descobertas para a língua inglesa apresentaram se manter para a língua portuguesa, tais como: milhares de regras são necessárias para cada nível adicional de análise, que as sentenças que excluem significado são mais frequentes que as que buscam e que a determinação do contexto concentra-se mais à esquerda da sentença. Tal tese explicita as principais diferenças entre o processamento sintagmático dos idiomas português e inglês, bem como suas diferenças e adaptações necessárias para se adequar ao idioma e ainda assim manter uma alta taxa de acerto.
% Uma união das abordagens listadas por \citeauthoronline{silva2014indexacao} e das desenvolvidas por \citeauthoronline{bick2000parsing}, \citeauthoronline{chaves2014sistema}, a fim de obter resultados mais precisos, será utilizada neste trabalho.
Segundo \citet{sardinha2000linguistica}, \aspas{[...] O Processamento de Linguagem Natural é uma disciplina com laços fortes com a Ciência da Computação e, embora compartilhe vários temas com a Lingüística de Corpus, as duas mantêm-se independentes.} (p. 328). Já de acordo com \citeonline[p. 55]{oliveira2009linguistica}, programas de processamento de linguagem natural são \aspas{[...] programas capazes de interpretar e/ou gerar informações em linguagem natural [...]}, onde (p. 55) \aspas{[...] a Linguística Computacional utiliza os corpora para poder ter acesso ao material que necessita estudar, ou seja, grande quantidade de textos que ocorrem naturalmente na língua.}\apudonline[p. 158]{trask2004dicionario}{aluisio2006constroi}, por sua vez, defende que \aspas{a partir de corpora, podem-se fazer observações precisas sobre o real comportamento lingüístico de falantes reais, proporcionando informações altamente confiáveis e isentas de opiniões e de julgamentos prévios sobre os fatos de uma língua}, onde tais observações seriam feitas com auxílio do resultado do processamento de um programa que processa os corpora, que por sua vez está codificado em linguagem natural. De todos estes autores, concluímos que o processamento da linguagem natural são estatísticas de um texto (ou de um conjunto deles) que são relevantes numa dada área do conhecimento.
\omissis{} um conjunto finito de enunciados tomados como objeto de análise. Mais precisamente, conjunto finito de enunciados considerados característicos do tipo de língua a estudar, reunidos para servirem de base à descrição e, eventualmente, à elaboração de um modelo explicativo dessa língua. Trata-se, pois, de uma colecção de documentos quer orais (gravados ou transcritos) quer escritos, quer orais e escritos, de acordo com o tipo de investigação pretendido. As dimensões do corpus variam segundo os objectivos do investigador e o volume dos enunciados considerados como característicos do fenômeno a estudar. Um corpus é chamado exaustivo quando compreende todos os enunciados característicos. E é chamado selectivo quando compreende apenas uma parte desses enunciados. \apud{galisson1983dicionario}{aluisio2006constroi}
\omissis{} corpus não pode ser considerado como constituindo a língua, mas somente como uma amostra da língua. (...) O corpus deve ser representativo, isto é, deve ilustrar toda a gama das características estruturais. Poder-se-ia pensar que as dificuldades serão levantadas se um corpus for exaustivo (...). Na realidade, sendo indefinido o número de enunciados possíveis, não há exaustividade verdadeira e, além disso, grandes quantidades de dados inúteis só podem complicar a pesquisa, tornando-a pesada.O lingüista deve, pois, procurar obter um corpus realmente significativo. Enfim, o lingüista deve desconfiar de tudo o que pode tornar o seu corpus não-representativo (método de pesquisa escolhido, anomalia que constitui a intrusão de lingüista, preconceito sobre a língua). \apud{dubois1993dicionario}{aluisio2006constroi}
Ou, de acordo com \apudonline{sinclair2005corpus}{aluisio2006constroi} como uma coleção de peças de um texto na forma eletrônica, selecionadas de acordo com critérios externos para representar, o quanto melhor possível, um idioma ou variação deste como dados fonte para pesquisa linguística. Por \apudonline[p. 31]{biber1995dimensions}{oliveira2009linguistica}, \aspas{um corpus linguístico de base computacional corresponde a coleções de textos que ocorrem naturalmente na língua, organizadas sistematicamente para representar áreas de uso da língua, e das quais podemos extrair novas informações}. Segundo \citet{oliveira2009linguistica}, linguística de corpus é uma ciência empírica, onde o pesquisador utiliza diversas vezes o corpus para estender uma descrição linguística, mas esta prática pode acabar por deixar a teoria aberta para mudanças. Então concluímos que linguística de corpus é a área do conhecimento que estuda a língua através de agrupamentos de textos da mesma que representam um nicho a ser estudado.
\citet{gries2010useful} ainda cita três estatísticas deriváveis de uma análise de corpus, sendo eles a frequência de ocorrência de um certo fenômeno no texto, dispersão e frequências ajustadas e frequências de co-ocorrência. A primeira (frequência de ocorrência de um certo fenômeno no texto) é uma contagem de quantas ocorrências algo foram identificadas no texto, a segunda (dispersão e frequências ajustadas) é a proporção (percentual) das ocorrências dado um corpus e sua dispersão e o último (frequências de co-ocorrência) age sobre a frequência de co-ocorrência de expressões linguísticas. Portanto estas são as principais informações que uma ferramenta para a linguística de corpus deve apresentar.
\section{Aspectos legais incidentes sobre aplicações de internet}
\label{marcocivil}
Popularmente chamado de \aspas{Marco Civil da Internet}, a lei nº 12.965, \aspas{estabelece princípios, garantias, direitos e deveres para o uso da internet no Brasil}\cite{lei12965}. Um dessses deveres pode se aplicar aos provedores das aplicações de internet, quando este for uma pessoa jurídica atuando com fins econômicos:
\begin{citacao}
Art. 15. O provedor de aplicações de internet constituído na forma de pessoa jurídica e que exerça essa atividade de forma organizada, profissionalmente e com fins econômicos deverá manter os respectivos registros de acesso a aplicações de internet, sob sigilo, em ambiente controlado e de segurança, pelo prazo de 6 (seis) meses, nos termos do regulamento. \cite{lei12965}
\end{citacao}
Onde o que constituem \aspas{registros de acesso a aplicações de internet} fora anteriormente definido no Art. 5º:
\begin{citacao}
VIII - registros de acesso a aplicações de internet: o conjunto de informações referentes à data e hora de uso de uma determinada aplicação de internet a partir de um determinado endereço IP. \cite{lei12965}
\end{citacao}
Portanto, para uma aplicação de internet ser usável comercialmente em território nacional sem inseguraça jurídica, deve ser auditável de forma a rastrear o endereço IP, data e hora de qualquer conteúdo gerado por qualquer usuário dentro da aplicação.
Este capítulo descreve as etapas do desenvolvimento da plataforma web proposta. Como plataforma web, compreende-se um software cuja interface seja acessível através de navegadores, como o Mozilla Firefox, por exemplo. A seção \ref{sec:des:req} descreve as etapas do levantamento de requisitos as funcionalidades desejáveis identificadas e as classes do domínio do problema, já a seção \ref{sec:des:nav} contém o projeto da navegabilidade e a seção \ref{sec:des:flux}, o projeto do fluxo de informações dentro da plataforma, e, por fim, a seção \ref{sec:des:train} contém a metodologia utilizada para treinar o etiquetador do Unitex/GramLab.
O levantamento de requisitos é uma das primeiras etapas do ciclo de vida de um projeto de software \cite{sommerville2011software}. Para tal, o primeiro passo foi pesquisar as ferramentas voltadas ao usuário final existentes. As ferramentas de processamento de corpora cujas interfaces não fossem em linha de comando mencionadas tando diretamente longo dos artigos citados no capítulo \ref{cha:ref} quanto mencionados nos \textit{sites} de projetos linguísticos mencionados nos artigos foram: \textit{WordSmith}, \textit{CorpusEye}, \textit{COCA Online Corpus}, \textit{Unitex/GramLab} e \textit{Sketch Engine}. Então, suas principais funcionalidades presentes na versão livre de custos foram levantadas, comparadas, e então expressas na tabela \ref{tab:comppln}, da qual foram extraídas, de forma não-exaustiva, características desejáveis de um sistema de processamento de corpora e listadas a seguir:
\item Possuir interface web compatível com tamanhos de tela diversos;
\item Processar corpora fornecidos pelo usuário;
\item Etiquetar corpora fornecidos pelo usuário;
\item Criar corpus a partir de buscas na internet;
\item Calcular estatísticas quanto à frequência de lemas e palavras;
\item Calcular estatísticas quanto à contagem de lemas e palavras;
\item Calcular estatísticas quanto à razão de lemas e palavras;
\item Calcular estatísticas quanto à contagem de sentenças e parágrafos;
\item Calcular estatísticas quanto ao tamanho em caracteres das palavras;
\item Calcular estatísticas quanto à quantidade de palavras por sentença;
\item Extrair as palavras-chave de um corpus;
\item Calcular estatísticas quanto à distribuição da palavra-chave no corpus;
\item Calcular estatísticas quanto às palavras relacionadas às palavras-chave do corpus;
\item Buscar por uma ocorrência de uma palavra ou sequência de palavras;
\item Buscar por uma expressão que simbolize uma construção textual;
\item Possuir um concordanciador;
\item Calcular os n-gramas mais frequentes de um texto.
\end{itemize}
Como nenhum dos softwares apresenta extensibilidade através de \textit{plug-ins} como funcionalidade, tal requisito não está presente na lista acima. Considerando que tal lista, apesar de extensa, pode não cobrir todos os casos de uso dum linguista e que nem todas as funcionalidades serão implementadas neste trabalho, julgamos desejável facilitar a adição e substituição de componentes do software por outros mais atualizados, com maiores taxas de acerto, computacionalmente mais eficientes e/ou com licenças mais permissivas, a critério do administrador do servidor que executa o software. Portanto possuir extensibilidade através de \textit{plug-ins} é um requisito do software.
Dos softwares anteriormente listados, observamos na tablela \ref{tab:comppln} que nenhum deles possui um concordanciador gratuito com suporte a etiquetas de partes do discurso para a língua portuguesa que receba textos quaisquer fornecidos pelo usuário. Adicionando esta funcionalidade como objetivo, juntamente de suas dependências, temos:
\begin{itemize}
\item Possuir extensibilidade através de \textit{plug-ins};
\item Possuir interface web compatível com tamanhos de tela diversos;
\item Processar corpora fornecidos pelo usuário;
\item Etiquetar corpora fornecidos pelo usuário;
\item Possuir um concordanciador.
\end{itemize}
Para gerar as páginas, foi escolhido o \textit{framework} Django em sua versão de longo suporte 1.11. Esta escolha se deve principalmente à prévia familiaridade do autor com a ferramenta. Outros fatores que influenciaram a decisão é a quantidade de bibliotecas disponíveis para a linguagem em que o \textit{framework} é escrito, Python, o que possibilita a inclusão destas nos \textit{plug-ins}.
Para que as páginas geradas sejam compatíveis com tamanhos de tela diversos, foi escolhido o \textit{framework} de folha de estilos Bootstrap em sua versão 4.0b1. Esta escolha também foi influenciada pela prévia familiaridade do autor. Em conjunto com a referida folha de estilos, também foi utilizado o pacote de ícones FontAwesome. Ele se define em sua página inicial como \aspas{um idioma pictográfico de ações relacionadas à \textit{web}}\cite{fontawesome2017home}. Foi adicionado visando melhorar a usabilidade.
Para processar os corpora fornecidos pelo usuário, foi selecionado o utilitário de linha de comando do \textit{software} Unitex/GramLab. É software livre licenciado sobre os termos da GPL, que não impõe restrições quanto ao seu uso. Apesar de possuir um utilitário chamado \aspas{Tagger}, somente durante a implementação foi observado que os arquivos necessários para sua utilização estavam presentes apenas para o idioma francês. Portanto, o etiquetador do Unitex/GramLab foi treinado para a língua portuguesa utilizando os corpora anotados pelo projeto Floresta Sintáctica (mais detalhes na seção \ref{sec:des:train}); em caso de resultados insatisfatórios (menos que 75\% de acertos), seria utilizado os arquivos previamente treinados do projeto Mac-Morpho nos etiquetadores MXPOST e TreeTagger.
\subsection{Classes do domínio do problema}
\label{subsef:des:cdp}
As classes do domínio do problema, quando representadas através da \textit{framework} utilizada, se aproximam muito do modelo lógico. O mapeamento objeto-relacional feito pela plataforma admite herança e classes abstratas; como a solução de persistência padrão é SQLite, e esta não suporta herança entre tabelas, o mapeador objeto-relacional replica os campos definidos na classe pai na classe filho, já classes abstratas não geram tabelas. A figura \ref{fig:class} traz o modelo lógico gerado automaticamente a partir da implementação com algumas alteração quanto à disposição dos elementos. A classe em magenta claro (\textit{User}) é advinda do \textit{framework}, já as demais classes em amarelo claro foram escritas para compor a base da plataforma, as quais os \textit{plug-ins} utilizarão diretamente. As classes com letras em cinza (\textit{Timestampable}, \textit{RequiresIP} e \textit{AttributeMixin}) são abstratas; todas as concretas herdam de \textit{RequiresIP}, devido às obrigações legais anteriormente mencionadas na seção \ref{marcocivil}.
%E de forma a encontrar os requisitos especificados nos objetivos (seção \ref{sec:obj}) a partir das principais ferramentas voltadas ao processamento de corpus de texto existentes no mercado. . A comparação completa de funcionalidades está prensente no apêndice \ref{ap:tabcomppln} em formato de tabela. Portanto, são funcionalidades desejáveis num sistema de processamento de linguagem natural:
%Como a proposta é de uma plataforma web, é esperado que seja usável a partir de um navegador como o Google Chrome, Opera ou Mozilla Firefox. Por conta disso, o sistema deverá gerar documentos HTML e transferí-los através do protocolo HTTP, que, segundo \citeonline{ross2013redes}, atua no camada de aplicação do modelo OSI. Portanto, será utilizada uma arquitetura cliente-servidor.
A navegabilidade no sistema é fundamental para a experiência do usuário. Os documentos de hipertexto formam um grafo, onde cada documento é um nó e cada link é uma aresta \cite{missing}. A forma que adotamos para representar tal navegação é através duma árvore (vide figura \ref{fig:arvnav}), onde a página anterior conhece seus descendentes imediatos e sua página pai, apenas. Embora tal forma não represente com precisão o estado final do sistema, com auxílio do quadro \ref{qua:cntdp}, tal modelo exerceu seu papel comunicativo durante o desenvolvimento.
Como ser extensível através de \textit{plug-ins} é um requisito da aplicação e este recurso não é oferecida pelo \textit{framework} sem que seja necessário alterar o arquivo de configuração, somado à vantagem de que os \textit{plug-ins} sejam substituíveis, julgamos preferível desenvolver tal parte do sistema utilizando uma arquitetura que favoreça o desacoplamento. Para tanto, escolhemos uma arquitetura baseada em eventos, onde cada \textit{plug-in} forneça e/ou consuma serviços de outros \textit{plug-ins} utilizando apenas eventos, sem consultar diretamente o outro \textit{plug-in} ou ser informado sobre quais estão instalados ou não.
A figura \ref{fig:flux:dt} mostra a árvore de diretórios em amarelo e seus \textit{scripts} em ciano. Na pasta \aspas{projeto} foram adicionados dois scripts: \aspas{gancho padrão} e \aspas{eventos}. O primeiro contém um gerador da estrutura que descreve um botão na página \aspas{Análise}. O segundo contém uma função \aspas{disparar} que recebe dois argumentos: uma cadeia de caracteres e um objeto qualquer; esta função dispara o evento e seu retorno depende da cadeia de caracteres de entrada, que especifica o tipo de evento: provedor, busca, filtro ou ação.
Eventos do tipo \aspas{provedor} descartam o segundo argumento de entrada e retornam uma lista. Foram idealizados para abastecer \textit{plug-ins} que aceitam recursos linguísticos além dos embarcados nele mesmo. Um exemplo de aplicação é um etiquetador que, através da resposta a eventos por ele disparados, recebe recursos para etiquetar idiomas originalmente não suportados.
Eventos do tipo \aspas{busca} recebem o objeto que está relacionado ao desejado no segundo argumento de entrada e retornam uma lista contendo o(s) resultado(s) de cada \textit{plug-in} que ofereceu aquele serviço de busca. Foram idealizados para buscar dados em outros \textit{plug-ins}, sem a necessidade de conhecer todos os modelos destes e sua representação interna. Um exemplo de aplicação é no concordanciador, onde ele fornece um corpus e recebe como resposta o \textit{cache} do corpora já etiquetado por cada etiquetador.
Eventos do tipo \aspas{filtro} recebem uma coleção de objetos no segundo argumento de entrada e retornam a uma coleção de tamanho menor ou igual, podendo ter elementos alterados, sendo a saída de um filtro a entrada do próximo. Foram idealizadas como forma de reduzir o conjunto de entrada, através de regras implementadas por outros \textit{plug-ins}. Um exemplo de aplicação são diversos tokenizadores atuando entre a lista de sentenças e o etiquetador, para garantir que a entrada do etiquetador seja consistente.
Eventos do tipo \aspas{ação} recebem um objeto qualquer e retornam nulo. Foram idealizados para notificar outros \textit{plug-ins} que uma ação foi concluída com sucesso, ou até mesmo para comunicação interna dentro do próprio \textit{plug-in}. Um exemplo de aplicação é num processamento conhecidamente demorado que é realizado em segundo plano e a notificação de sua conclusão se dá através de um \textit{e-mail}.
A figura \ref{fig:flux:init} traz a sequência de inicialização do subsistema de eventos. O primeiro arquivo que o \textit{framework} Django carrega é o de configurações (seta \aspas{1}), que foi utilizado para inicializar o subsistema de eventos (seta \aspas{2}), que, por sua vez, carrega os \aspas{ganchos} (setas \aspas{3} e \aspas{4}) do primeiro \aspas{plug-in} e todos os demais (setas \aspas{5}, \aspas{6}, \aspas{7}, \aspas{x}, \aspas{x+1} e \aspas{x+2}), termina sua configuração interna, retorna a execução ao arquivo de configurações (seta \aspas{x+3}), que atualiza os endereços disponíveis (setas \aspas{x+4} e \aspas{x+5}) e retorna à execução normal do \textit{framework} (seta \aspas{x+6}).
A figura \ref{fig:flux:base} traz como exemplo o cenário de exibir um formulário para editar um documento pertencente a um corpus. O \textit{framework} busca o endereço especificado pela requisição (seta \aspas{1}) e encontra uma entrada para uma classe de controlador no arquivo de \aspas{visões} presente no pacote \aspas{páginas} (seta \aspas{2}), que, por sua vez, carrega o dado (setas \aspas{3} e \aspas{4}), o formulário (seta \aspas{5} e \aspas{6}), monta como resposta um documento HTML usando um arquivo de \textit{template} (omitido do modelo) e retorna a resposta (seta \aspas{7}).
A figura \ref{fig:flux:list} traz como exemplo uma requisição para listar os \textit{plug-ins} na página \aspas{Análise}. O \textit{framework} busca o endereço especificado pela requisição (seta \aspas{1}) e encontra a entrada para a classe controladora da página \aspas{Análise} no pacote \aspas{páginas} (seta \aspas{2}), onde tal controlador dispara consultas para os \aspas{ganchos} de cada \textit{plug-in} (seta \aspas{3}) e cada \aspas{gancho} carrega o gerador de \aspas{ganchos} do \textit{script}\aspas{gancho padrão} (setas \aspas{4} e \aspas{5}) e os altera conforme suas necessidades, o retorna ao controlador (seta \aspas{6}), que gera a página a partir de um \textit{template} e a retorna (seta \aspas{7}).
A figura \ref{fig:flux:plugin} traz como exemplo uma requisição para buscar uma lista de sentenças associada a um corpus. As setas \aspas{1} e \aspas{2} seguem o mesmo algoritmo dos parágrafo anterior, mas é executada uma classe controladora no arquivo de visões do \textit{plug-in}, que por sua vez carrega o corpus a partir dos modelos da aplicação (setas \aspas{3} e \aspas{4}), que, por sua vez, é utilizada para carregar a lista de sentenças em seu modelo interno para, enfim, gerar o documento de resposta e retorná-lo ao usuário (seta \aspas{7}).
Por fim, a figura \ref{fig:flux:event} traz como exemplo uma requisição para buscar uma concordância, que depende duma lista de palavras etiquetada fornecida por outros \textit{plug-ins} através de eventos. Novamente, as setas \aspas{1} e \aspas{2} seguem o mesmo algoritmo dos parágrafo anterior, que, desta vez, termina por executar o controlador presente no arquivo de visões do concordanciador, que dispara um evento de busca (seta \aspas{3}), que acaba por executar código definido durante a inicialização presente nos arquivos da \aspas{extensão 1} (setas \aspas{4} e \aspas{5}) e da \aspas{extensão 2} (setas \aspas{6} e \aspas{7}), retornando ao controlador uma lista do corpus etiquetado por diferentes etiquetadores (seta \aspas{8}), que processa os dados, gera um documento e o retorna ao usuário (seta \aspas{9}).
Conforme mencionado anteriormente no final da subseção \ref{subsec:des:reqsol}, o etiquetador do Unitex/GramLab foi treinado utilizando os corpora anotados do Floresta Sintáctica, que oferece os corpora nos formatos CoNLL e Árvore Deitada. O formato inicialmente escolhido foi o CoNLL, mas rapidamente ele demonstrou não possuir uma estrutura consistente (a exemplo, as \aspas{tags}\aspas{XML} que determinam o início das sentenças possuía um atributo ora nomeado \aspas{text}, ora nomeado \aspas{texto}). Portanto, foi utilizado os arquivos no formato de árvore deitada.
Após converter os corpora anotados para o formato de entrada do treinador do Unitex/GramLab, era o momento de separar em treino e teste, mas não era sabido quais corpora gerariam erros devidos a eventuais erros na conversão do formato não documentado. A solução adotada foi testar cada corpus anotado: caso o treino concluísse com sucesso era separado para o conjunto treino, caso contrário, para o de teste. Resultados no quadro \ref{qua:stt}.
O conjunto de treino continha 1.286.251 palavras anotadas distribuídas ao longo de 81.438 sentenças; já o conjunto de testes continha 4.585.010 palavras distribuídas ao longo de 266.500 sentenças. Devido a diferenças no tokenizador e separador de sentenças, o teste etiquetado continha 4.726.605 palavras anotadas ao longo de 245.718 sentenças. Separando apenas as sentenças que foram \aspas{tokenizadas} da mesma forma que no conjunto de testes, temos 2.801.255 palavras em 176.034 sentenças. Sendo a proporção treino/teste de aproximadamente 46\%, os resultados do podem ser observados na seção \ref{sec:res:train} do capítulo de resultados.
%\subsection{Analisar comparativamente os recursos das principais ferramentas existentes}
%Foi identificado que as plataformas WordSmith, CorpusEye, COCA Online Corpus, Unitex/GramLab e Sketch Engine provém recursos semelhantes aos desejados. Tais recursos desejados são os mesmos citados na seção de objetivos específicos (subseção \ref{obj:esp}), nos itens 2, 3 e 4. Não se limitado apenas às funcionalidades listadas, tais atributos foram anotados na tabela da figura \ref{fig:cfn} presente no capítulo de resultados (seção \ref{res:cfn}).
%A ferramenta desenvolvida ser livre é um requisitos expressos no objetivo geral (subseção \ref{obj:ger}). A única ferramenta livre para etiquetagem morfossintática da língua portuguesa é o Unitex/Gramlab, como mencionado no estado da arte dos etiquetadores morfossintáticos para o português na subseção \ref{ea:em}. Portanto o etiquetador escolhido foi o Unitex/Gramlab.
%Para a interface web, outro requisito expresso no objetivo geral (subseção \ref{obj:ger}), foi escolhido o \textit{framework} Django. Este utiliza a linguagem de programação Python para servir páginas HTML dinâmicas. Tanto a linguagem quanto o \textit{framework} foram escolhas do autor por estes já serem conhecimentos prévios ao início deste trabalho.
%\subsection{Mapear as funcionalidades da interface gráfica em Java do Unitex/GramLab para ações em linha de comando}
%O Unitex/GramLab possui uma \aspas{janela} em sua interface na qual é possível visualizar todos os comandos \aspas{disparados} na linha de comando. Através da sequência de comandos executados, foi inferido um padrão para cada elemento da interface e seu impacto na linha de comando. Resultados disponíveis na seção (seção \ref{res:clire}).
%Todos os módulos desenvolvidos necessitam operar de forma coerente, de modo a priorizar a interdependência entre funcionalidades providas pelos pacotes. Para tanto foi separado os pacotes que definem as interfaces dos pacotes que definem as visualizações e dos pacotes que implementam a funcionalidade, de modo a criar reforçar uma hierarquia de dependências que permitam extensibilidade de funcionalidades. O resultado esperado é reduzir o acoplamento entre diversos \textit{plug-ins}, formando uma árvore de dependências entre pacotes.
% Para a construção da plataforma modular será utilizada a linguagem de programação Python em sua versão 3 em conjunto ao framework DJango. Isso \aspas{obriga} que os módulos sejam escritos também em Python. O módulo concordanciador usará o software Unitex/GramLab para obter as marcações.
% ...apesar do PALAVRAS ser o atual estado da arte, este não pode ser utilizado por não ser completamente livre. Decidimos, portanto, utilizar o Unitex/GramLab, por ser livre.
\textit{repetir a problemática da falta de uma ferramenta que faça tudo, a de padronização na área, e ressaltar como}
\section{Trabalhos futuros}
\textit{lista de tópicos mencionando: trocar plugins que baixam código proprietário por que sejam completamente livres, mais plugins (de preferencia, livres), interface para adicionar e atualizar plugins a partir de repositórios GIT, caça aos bugs, o que refatorar na plataforma, implementar a api JSON que \aspas{não saiu a tempo}, estudo de caso com uma turma real}
O código fonte da plataforma desenvolvida neste trabalho está publicamente disponível tanto em \url{https://github.com/adlerosn/corpusslayer}, quanto em \url{https://git.adlerosn.com/root/corpusslayer}.
