Linked Open Data sobre arte rupestre presente no Vale do Côa

Universidade do Minho Escola de Engenharia Maria Inês Marques Miguel Linked Open Data sobre arte rupestre presente no Vale do Côa outubro de 2022 Linked Open Data sobre arte rupestre presente no Vale do Côa Maria Inês Marques Miguel UMinho | 202X Maria Inês Marques Miguel (A84114) Linked Open Data sobre arte rupestre presente no Vale do Côa outubro de 2022 Dissertação de Mestrado Mestrado integrado em Engenharia e Gestão de Sistemas de Informação Trabalho efetuado sob a orientação da Professora Doutora Ana Alice Rodrigues Pereira Baptista v DIREITOS DE AUTOR Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ vi AGRADECIMENTOS Primeiramente, gostaria de agradecer todo o apoio, sabedoria, paciência, compreensão e simpatia da minha orientadora Professora Doutora Ana Alice Rodrigues Pereira Baptista. Foi graças a todo o seu apoio que esta dissertação foi concluída com todo o rigor. Gostaria também de agradecer à Engenheira Natália Botica pela simpatia, ajuda e apoio prestados, relativamente à área de arqueologia abordada neste projeto, tendo sido também fundamental para o seu desenvolvimento com o máximo de exatidão. Aos meus pais, por todo o sacrifício feito para que eu conseguisse ingressar na universidade e concluir os meus estudos. Graças a eles eu consegui me tornar na pessoa que sou hoje, e sem dúvida alguma que, apesar de tudo, eles me educaram da melhor forma que conseguiram. Sem eles eu não estaria aqui e não teria conseguido alcançar os meus sonhos. À minha melhor amiga, Cristiana, que me apoiou em todos os meus momentos de stress, dando sempre ótimos conselhos que me ajudaram imenso a crescer como pessoa, e a conseguir não desistir em momentos mais complicados. Ela é uma pessoa fundamental na minha vida! Às minhas colegas de casa, Inês e Léa, que durante estes 5 anos de curso, me ajudaram imenso e me fizeram sentir acolhida, com a sua amizade e companheirismo! A todas as pessoas que conheci nesta Universidade, e que fizeram a diferença na minha vida, agradeço imenso por todas as experiências e oportunidades que me ajudaram a aproveitar. Estes anos deixarão saudade, mas foram anos que me ensinaram bastante tanto a nível profissional como pessoal. Obrigada, Universidade do Minho! vii DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio, nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. viii RESUMO Linked Open Data sobre arte rupestre presente no Vale do Côa Atualmente, a necessidade de ligar e relacionar dados de diversas fontes, vai sendo cada vez maior, e é aí que a Web Semântica vem dar uma solução. Essa solução consiste na utilização de Linked Open Data, que através da uniformização dos padrões e vocabulários utilizados, permite a sua interoperabilidade com outros dados. Neste projeto de investigação será utilizada a base de dados da Unidade de Arqueologia da Universidade do Minho. Atualmente os seus dados não estão disponíveis abertamente, dificultando a sua utilização por investigadores fora da Universidade. O objetivo é tornar alguns dados dessa base de dados em Linked Open Data, de forma a permitir que outros investigadores possam utilizá-los e relacioná-los com outros dados. Para a realização da revisão de leitura foi utilizado o método PRISMA. Esta revisão de leitura é necessária visto que é bastante importante ter uma boa base teórica de forma que todos os passos necessários à sua concretização sejam realizados de maneira correta. Com a revisão concluída, foram exploradas algumas ontologias, dando enfânse no CIDOC CRM, para perceber quais são as opções de modelos de estruturação de dados disponíveis e que poderão ser utilizados. Foram também explorados os conceitos base desta área, tais como o que é a Web Semântica e as suas componentes principais, tendo sido também explorado o que é um Linked (Open) Data. Em adição, foram explorados projetos semelhantes ao que este projeto de investigação pretende desenvolver, de forma a perceber que tecnologias foram utilizadas e se alguma será útil para a implementação neste projeto. É também explicado o método de investigação utilizado, o Design Science Resarch, e o método de criação de um Perfil de Aplicação, o Dublin Core Tabular Application Profile, um dos pontos fulcrais do projeto. Como resultados temos o Perfil de Aplicação criado no âmbito deste projeto, os dados transformados para RDF e inseridos num triplestore, um esquema de classes e propriedades e um vocabulário controlado codificado em SKOS. Este projeto torna-se bastante útil para quem pretender transformar dados arqueológicos em Linked Data, pois são especificados todos os passos tomados no seu desenvolvimento. Palavras chave: Arqueologia; Dublin Core Tabular Application Profile; Linked Open Data; RDF. ix ABSTRACT Linked Open Data on rock art present in the Côa Valley Currently, the need to link and relate data from various sources is increasing, and that is where the Semantic Web comes to provide a solution. This solution is the use of Linked Open Data, which through the standardization of standards and vocabularies used, allows its interoperability with other data. In this research project, the database of the Archaeology Unit of the University of Minho will be used. Currently, its data is not openly available, making its use by researchers outside the University difficult. The goal is to make some data from this database Linked Open Data, to allow other researchers to use it and relate it with other data. The PRISMA method was used to conduct the reading review. This reading review is necessary, since it is quite important to have a good theoretical base, so that all the steps needed to accomplish it are done correctly. With the review completed, some ontologies were explored, focusing on CIDOC CRM, to understand what options of data structuring models are available and that could be used. The basic concepts of this area were also explored, such as what is the Semantic Web and its main components, and what is Linked (Open) Data. In addition, similar projects to the one that this research project intends to develop were explored, to understand what technologies were used and if any will be useful and a potential implementation on this project. The research method used, Design Science Research, is also explained, as well as the method of creating an Application Profile, the Dublin Core Tabular Application Profile, one of the project’s focal points. As results we have the Application Profile that was created within this project, the data transformed to RDF and inserted into a triplestore, a schema of classes and properties and a controlled vocabulary encoded in SKOS. This project becomes very useful for those who intend to transform archaeological data into Linked Data, because all the steps taken in its development are specified. Keywords: Archaeology; Dublin Core Tabular Application Profile; Linked Open Data; RDF. x ÍNDICE Direitos de autor ........................................................................................................................ v Agradecimentos ........................................................................................................................ vi Declaração de integridade ....................................................................................................... vii Resumo .....................................................................................................................................viii Abstract ..................................................................................................................................... ix Lista de abreviaturas/Siglas ...................................................................................................... xiii Lista de figuras........................................................................................................................... xv Lista de tabelas ........................................................................................................................ xvii 1. Introdução ........................................................................................................................... 1 1.1 Problemas e objetivos .................................................................................................. 2 1.2 Possíveis Contributos ................................................................................................... 4 2. Contextualização ................................................................................................................. 5 2.1 Base de dados .............................................................................................................. 5 2.2 Vocabulários Controlados .......................................................................................... 12 3. Fundamentos e Trabalho Relacionado ............................................................................. 14 3.1 Web Semântica e Linked (Open) Data ....................................................................... 14 3.2 CIDOC CRM ................................................................................................................. 24 3.3 DBpedia ...................................................................................................................... 26 3.4 Projetos LOD .............................................................................................................. 27 4. Procedimentos Metodológicos ......................................................................................... 41 4.1 Design Science Research ............................................................................................ 41 4.2 Me4MAP .................................................................................................................... 46 4.3 Dublin Core Tabular Application Profile..................................................................... 48 1 1. INTRODUÇÃO O Parque Arqueológico do Vale do Côa, que se situa no distrito da Guarda, tem uma área de 200 km2. Nesta área estão localizados mais de 80 lugares com a presença de arte rupestre e cerca de 1200 rochas gravadas, sendo considerado o maior conjunto mundial de arte paleolítica ao ar livre. Alguma desta arte pertence ao período Neolítico e da Idade do Ferro. O rio Côa é delimitado por rochas de xisto que fazem parte dessas 1200. Estas foram convertidas em painéis de arte rupestre, com gravuras milenares. (CoaParque, 2022b, 2022a) A Figura 1 apresenta um exemplo de arte rupestre presente no museu. Figura 1: Exemplo de arte ruprestre do Vale do Côa (Fonte: https://arte-coa.pt/museu/) Este parque tem como missão “gerir, proteger, investigar e mostrar ao público a arte rupestre” (CoaParque, 2022). A Unidade de Arqueologia da Universidade do Minho (UAUM) tem explorado este parque à procura de arte rupestre da Idade do Ferro, de forma a aumentar o seu conhecimento sobre ela, e sobre as sociedades que a criaram. Para isso tem sido feito trabalho de campo em zonas específicas, escolhidas pela equipa da UAUM, sendo como exemplo destas, Vermelhosa, Vale de José Esteves, Quinta das Tulhas e Meijapão. (Botica & Figueiredo, 2020) Toda informação sobre a arte encontrada é inserida na base de dados, criada para o efeito do seu sistema 2ArchIS. O 2ArchIS é um sistema modular e interliga toda a informação proveniente do processo de investigação. De forma a inserir essa informação no sistema foi criada uma aplicação backoffice, com interface web desenvolvida em PHP e HTML que permite 2 a sua utilização tanto em escritório quanto em campo. A base de dados baseia-se num modelo de dados relacional. As tabelas desta base de dados mais relevantes para este projeto de investigação são, Sitio/Núcleo, Afloramento, Motivo, Parte Representada, Cena e Motivo Cena. Estas serão explicadas de forma mais aprofundada no Capítulo 2. É possível consultar, com critérios pré-definidos, os dados presentes na sua base de dados através de um formulário localizado na aplicação backoffice. Este vasto conjunto de dados é utilizado pela UAUM no desenvolvimento de relatórios técnicos e artigos científicos, que mais tarde são publicados no repositório da Universidade do Minho. 1.1 Problemas e objetivos Atualmente, existem diversas bases de dados com dados arqueológicos. Estas bases de dados, que podem conter dados de interesse público, na maioria das vezes estão fechadas, ou se caso contrário, estiverem abertas, não são semanticamente interoperáveis com outras. Isto torna-se um grande problema para a sua utilização por parte de outros investigadores e profissionais no país e no estrangeiro, e também para o relacionamento e agregação de dados de outras bases de dados que tenham aspetos comuns. De forma a tornar estes dados num contributo para a ciência aberta em Arqueologia, é necessário que estes sejam inseridos em repositórios abertos, garantindo assim a sua acessibilidade, perenidade e a sua reutilização, sendo este um ponto bastante importante no processo de investigação. Para que isto seja possível é necessário que os dados sejam modelados como FAIR (Findable, Accessible, Interoperable and Reusable), utilizando padrões uniformes entre a comunidade. Esta é uma prática pouco adotada e como consequência, neste momento, estes dados não estão facilmente acessíveis. É aqui que entra a importância deste projeto de investigação, ao tornálos LOD, para além de concretizar os pontos referidos anteriormente ainda será possível aumentar o reconhecimento dos autores e do seu trabalho, promovendo assim a sua reutilização e aumentar o conhecimento sobre a arte rupestre da Idade do Ferro do Vale do Côa, e sobre as civilizações que a criaram. (Botica et al., 2022) 3 Com isto, é possível delimitar os principais objetivos deste projeto, sendo estes: • Tornar possível ligar os dados a outras fontes de dados relacionados na Web, permitindo novas perspetivas e descobertas, ao torná-los Linked Open Data; • Melhorar a interoperabilidade dos dados, através da utilização de ontologias e vocabulários controlados para representar e ligar dados; • Permitir que os dados permaneçam acessíveis e utilizáveis por investigadores e profissionais externos à Universidade do Minho. Um requisito deste projeto consiste na interoperabilidade com o projeto ARIADNE, visto ser necessário utilizar os seus padrões para que se torne possível que os dados resultantes deste projeto possam fazer parte da sua base de dados. 4 1.2 Possíveis Contributos Concretizando-se este projeto, serão criados alguns contributos para a sua área, sendo eles: • Application Profile; • Vocabulários controlados codificados em SKOS; • Classes e propriedades criadas; • Disponibilização dos dados. De forma a demonstrar todo o processo realizado, primeiro é feita uma contextualização da base de dados da UAUM, explicando cada entidade e os seus atributos mais importantes, depois são explicados os fundamentos importantes para este projeto e o trabalho relacionado. São mencionados os procedimentos metodológicos utilizados neste projeto, e posteriormente é explicado o desenvolvimento e implementação de um desses procedimentos metodológicos, o DCTAP. É explicado como foi feita a transformação, carregamento e disponibilização dos dados, e de seguida é feita a sua validação. Por fim, é feita uma conclusão, dando um contexto, relacionando os resultados com os objetivos, e mencionando as limitações e trabalho futuro. 5 2. CONTEXTUALIZAÇÃO Neste capítulo serão dadas contextualizações da base de dados, que será utilizada como base deste projeto, e dos vocabulários controlados que são utilizados pela UAUM. 2.1 Base de dados Tal como explicado no Capítulo 1, a base de dados da UAUM é constituída por entidades e atributos importantes para o desenvolvimento deste projeto. As entidades principais são “sitio_nucleo”, “afloramento”, “motivo”, “parte_representada”, “cena” e “motivo_cena”. Na Figura 2 é possível observar o modelo simplificado da base de dados, onde estão presentes as entidades mencionadas. Figura 2: Modelo simplicado da base de dados da UAUM De forma a ser percetível a importância de cada uma, será feita uma explicação detalhada para cada entidade. 6 2.1.1 Entidade Sítio/Núcleo Começando pela entidade “sitio_nucleo”, esta identifica os diversos sítios arqueológicos que foram explorados pela equipa da UAUM. Um sítio arqueológico trata-se de um local onde foram preservadas evidências de atividades de civilizações passadas. Os atributos, que a constituem, são: • Id_mon – Número de identificação do sítio ou núcleo; • Nome – Nome pelo qual o sítio ou núcleo é identificado; • Topónimo – Nome geográfico do sítio ou núcleo; • Conservação – Estado de conservação do sítio ou núcleo; • Descrição – Descrição do sítio ou núcleo; • Interpretação – Interpretação do sítio ou núcleo; • Classificação – Classificação do sítio ou núcleo; • Código Classificação – Código Nacional de Sítio Arqueológico; • Área – Área total do sítio ou núcleo; • Lugar – Lugar onde se encontra o sítio ou núcleo; • Concelho – Concelho onde o sítio ou núcleo está localizado; • Freguesia – Freguesia onde se encontra o sítio ou núcleo; • Coordenadas X – Longitude da localização exata do sítio ou núcleo; • Coordenadas Y – Latitude da localização exata do sítio ou núcleo; • Coordenadas Z – Altitude da localização exata do sítio ou núcleo; • Acessos – Acessos disponíveis para o sítio ou núcleo; • Tipo Acesso – Tipos dos acessos disponíveis para o sítio ou núcleo; • Observações – Observações sobre o sítio ou núcleo. Na Figura 3 pode ser observada a entidade e os seus atributos. 7 Figura 3: Entidade "sitio_nucleo" e os seus atributos 2.1.2 Entidade Afloramento Relativamente à entidade “afloramento”, esta descreve todos os afloramentos encontrados pelos diversos sítios arqueológicos explorados. Um afloramento é a exposição de uma rocha ou camada na superfície do terreno. Os atributos, que a constituem, são: • Id_mon – Número de identificação do sítio ou núcleo onde o afloramento se encontra; • Id_material – Número de identificação do afloramento; • Número de Inventário – Número do inventário da UAUM ao qual o afloramento está identificado; • Descrição – Descrição sobre o afloramento; • Coordenadas X – Longitude da localização exata do afloramento; • Coordenadas Y – Latitude da localização exata do afloramento; • Coordenadas Z – Altitude da localização exata do afloramento; • Tipo Suporte – Tipo de suporte geológico do afloramento • Litologia – Constituição rochosa do afloramento; • Formação Litológica – Nome do conjunto de rochas, onde o afloramento está localizado; • Cor – Cor do afloramento; • Conservação – Estado de conservação do afloramento; 8 • Morfologia Superfície – Estrutura da superfície do afloramento; • Aspeto Superfície – Aspeto da superfície do afloramento; • Termo de Alteração – Termo de alteração do afloramento; • Direção – Direção à qual o afloramento está orientado; • Inclinação – Inclinação do afloramento; • Estratigrafia – Inclinação – Inclinação da estratigrafia do afloramento; • Comprimento – Comprimento do afloramento; • Altura – Altura do afloramento; • Observações – Observações sobre o afloramento; Na Figura 4 é possível observar todos os atributos que a constituem. Figura 4: Entidade "afloramento" e os seus atributos 2.1.3 Entidade Motivo A entidade “motivo” descreve todos os motivos encontrados nos diversos afloramentos. Um motivo trata-se de uma imagem, ou parte dela, onde estão representadas as gravuras rupestres. Os atributos, que a constituem, são: • Id_mon – Número de identificação do sítio ou núcleo no qual o afloramento, onde o motivo se encontra, está localizado; 9 • Id_material – Número de identificação do afloramento onde o motivo se encontra; • Id_motivo – Número de identificação do motivo; • Número Inventário – Número de inventário da UAUM ao qual o motivo está identificado; • Descrição – Descrição sobre o motivo; • Conservação – Estado de conservação do motivo; • Cronologia – Período temporal em que o motivo foi desenhado; • Estilo – Estilo do motivo; • Técnica – Técnica utilizada para o desenho do motivo; • Técnica Variante – Especificação da técnica utilizada para o desenho do motivo; • Patine – Estado da presença de patine no motivo; • Largura – Largura do motivo; • Altura – Altura do motivo; • Grupo – Grupo ao qual o motivo pertence; • Tipo – Tipo do motivo, derivado do seu grupo; • Subtipo – Subtipo do motivo, dependente do seu tipo; • Figura – Identifica se a figura está completa ou não; • Invertida – Identifica se a figura está invertida ou não; • Orientação – Orientação, em graus, do motivo; • Animação – Tipo de animação do motivo; • Relação Suporte – Relação, do motivo, com o seu suporte; Na Figura 5 é possível observar, com maior detalhe, todos os atributos relevantes que a constituem. 10 Figura 5: Entidade "motivo" e os seus atributos 2.1.4 Entidade Parte Representada A entidade “parte_representada” descreve todas as partes representas nos diversos motivos encontrados. Uma parte representada pode se referir a partes do corpo de antropomorfos e zoomorfos ou partes de armas. Os atributos, que a constituem, são: • Id_mon – Número de identificação do sítio ou núcleo; • Id_material – Número de identificação do afloramento; • Id_motivo – Número de identificação do motivo; • Id_motivo_partes – Número de identificação da parte representada; • Parte Representada – Identificação de qual a parte que está representada no motivo; • Forma – Forma da parte representada; • Número – Número de vezes que a parte está representada; • Posição – Posição da parte representada no motivo; • Perspetiva – Perspetiva da parte representada no motivo; • Técnica – Técnica utilizada para o desenho da parte representada; • Técnica Variante – Especificação da técnica utilizada para o desenho da parte representada; 17 3.1.1 RDF O Resource Description Framework (RDF) é um modelo utilizado para o intercâmbio e representação de dados na Web, sendo uma recomendação W3C desde 1999. Este utiliza URIs para identificar os recursos, permitindo que “os dados estruturados e semiestruturados sejam misturados, expostos, e partilhados entre diferentes aplicações” (RDF Working Group, 2014). Os dados representados em RDF têm uma estrutura em triplos. Um exemplo desta estrutura é “A Web semântica é uma extensão da World Wide Web”, onde o sujeito neste caso é a “Web Semântica”, o objeto é a “World Wide Web”, e o predicado, que liga os dois anteriores e mostra qual a sua relação, é “uma extensão”. O conjunto de dados estruturados dessa forma dá origem a um grafo. Na Figura 10 está representado o grafo resultante do exemplo dado anteriormente. Quando os dados são apresentados através de um retângulo, estes são dados representados em texto, sendo considerados dados literais, e os restantes, apresentados através de um círculo ou oval, são dados representados através de URIs, sendo considerados não literais. (Gutierrez et al., 2007) Figura 10: Exemplo grafo RDF Na Figura 11 é apresentado um grafo resultante deste projeto. Figura 11 - Exemplo de um grafo resultante de um Motivo 18 3.1.2 SKOS O Simple Knowledge Organization System (SKOS) é um modelo de dados que envolve sistemas de organização do conhecimento, partilhando e ligando-os através da Web. Este modelo torna explícitas as semelhanças entre esses sistemas, de forma a permitir que haja uma partilha de dados e tecnologia. Podendo também ser utilizado em conjunto com a linguagem OWL. (Semantic Web Deployment Working Group, 2009; Wikimedia Foundation, 2021a) O SKOS fornece um padrão de representação utilizando RDF e é uma recomendação W3C. O SKOS fornece um conjunto de classes e propriedades para a representação de vocabulários controlados. Um vocabulário controlado consiste numa lista de termos que se podem relacionar entre si e que ajudam os autores a rotular de forma uniforme os seus dados, permitindo assim que os utilizadores os encontrem e identifiquem facilmente. Existem 7 tipos de vocabulários controlados, sendo estes: (Jorge et al., 2017) • Cabeçalhos de assunto – Consistem em uma ou mais palavras que descrevem um assunto ou um tema, podendo assim agrupar vários assuntos em uma única frase; • Listas controladas – Consistem em listas que contêm termos únicos, sem haver a sua sobreposição de significado, todos pertencem à mesma classe, não têm hierarquia e estão organizados por ordem alfabética ou outra ordem lógica. Estes termos podem ser provenientes de outros vocabulários controlados, tendo a capacidade de, em alguns casos, serem suficientes para garantir o controlo de termos; • Anéis de sinónimos – Consistem em conjuntos de termos que são equivalentes, podendo estes serem sinónimos, relacionados ou similares; • Listas de autoridade – Consistem em conjuntos de entidades com nomes próprios, tais como pessoas ou organizações. Estas listas identificam, para cada elemento, o nome preferencial e alternativo; (Almeida & Costa, 2022) • Sistemas de classificação – Consistem em códigos controlados que servem para representar cabeçalhos ou conceitos, possuindo uma taxonomia implícita; • Taxonomias – Consistem em vocabulários facetados, com termos organizados de forma hierárquica e relacionados entre si, esse relacionamento pode variar de tipo. A sua diferença em relação a Tesauros passa pelo número de níveis hierárquicos ser menor, e serem menos complexos em termos estruturais; 19 • Tesauros – Consistem em redes semânticas de conceitos, sendo estes conceitos únicos e que podem se relacionar de três tipos diferentes, sinónimos, hierarquia e associação. Adicionalmente, pode armazenar informação relativa a um conceito, sendo esta da escolha do autor. Um exemplo de um tesauro é o Thesaurus da UNESCO 1 . A classes e propriedade do SKOS, utilizadas para a representação de vocabulários controlados, tais como os explicados anteriormente, estão divididas nas seguintes categorias (W3C Working Group Note, 2009): • Concepts – São os elementos fundamentais do SKOS, são o que identificam um conceito, através da classe skos:Concept; • Labels – São os identificadores textuais dos conceitos, representando a sua etiqueta. Existem três tipos, os Preferred Lexical Labels (skos:prefLabel), que são os que identificam o nome preferencial do conceito, podendo haver um para cada língua existente. Os Alternative Lexical Labels (skos:altLabel), que correspondem aos identificadores textuais alternativos, sendo que aqui poderão ser apresentados sinónimos dos Preferred Lexical Labels, nas várias línguas em que estes forem identificados, mas nunca o mesmo, e os Hidden Lexical Labels (skos:hiddenLabel) que se trata de um identificador textual oculto, podendo ser utilizado para identificar possíveis variações com erros gramaticais, de forma a poderem ser encontrados na mesma; • Semantic Relationships – São fundamentais na definição de um conceito, pois as suas ligações a outros conceitos do mesmo vocabulário, dão-lhe um significado adicional ao que já é dado pelo seu nome. Estas relações podem ser representadas por skos:broader ou skos:narrower, sendo estas duas relações hierárquicas, onde a primeira é utilizada num conceito para identificar um que seja mais amplo que esse e a segunda é utilizada para identificar um conceito mais específico que esteja relacionado a si. Desta forma é criada uma hierarquia onde um conceito identificado com skos:broader está num nível hierárquico acima do conceito onde foi identificado, e um conceito identificado com skos:narrower está num nível 1 https://vocabularies.unesco.org/browser/thesaurus/en/ 20 hierárquico abaixo do conceito onde foi identificado. Outra possibilidade de representação de uma relação é a skos:related que permite identificar conceitos relacionados de uma forma não hierárquica, sendo uma ligação associativa. • Documentary Notes – Estas são bastante úteis para documentar qualquer tipo de recursos, sendo que a propriedade central para essas notas é a skos:note, que é utilizada para documentação menos específica. Derivadas dessa propriedade existem quatro propriedades mais específicas, sendo estas, a skos:scopeNote que permite documentar sobre o âmbito de utilização de um conceito, podendo este ser apenas parcial, a skos:definition que ao contrário do anterior, fornece uma explicação completa do significado pretendido de um conceito, a skos:example que fornece um exemplo de como o conceito pode ser utilizado e a skos:historyNote que permite descrever possíveis alterações consideráveis no significado ou forma de um conceito. Para além destes, existem dois tipos de notas que são direcionadas para editores do código SKOS, a skos:editorialNote que identifica possíveis mudanças ou tarefas a realizar, sendo uma ajuda à gestão administrativa, e a skos:changeNote que identifica possíveis mudanças em conceitos, com propósitos de mudança ou manutenção; • Concept Schemes – Esta é uma forma útil de criar tesauros. Com a criação de um esquema de conceitos, e utilizando a classe skos:ConceptScheme, é possível identificar um conceito central, e os conceitos que estão diretamente relacionados e dentro desse são identificados com skos:inScheme. Para facilitar a ligação aos conceitos mais gerais desse esquema, é utilizada a propriedade skos:hasTopConcept. Os Concept Schemes serão utilizados na criação do vocabulário controlado para este projeto. Portanto, o SKOS é utilizado para representar qualquer tipo de vocabulário estruturado e controlado, levando a uma fácil partilha desses vocabulários como Linked Data. (Semantic Web Deployment Working Group, 2009; Wikimedia Foundation, 2021a) Uma alternativa ao SKOS é a linguagem OWL (Ontology Web Language). Mesmo a OWL sendo mais completa que o SKOS, foi escolhido o SKOS para ser utilizado neste projeto, dada a sua natureza, e a necessidade da codificação de um vocabulário controlado, onde o SKOS torna esse processo menos complexo. 21 3.1.3 SPARQL A SPARQL Protocol and RDF Query Language (SPARQL) é uma linguagem de consulta semântica para RDF. A consulta dos dados é realizada através de queries. (Idehen, 2019; SPARQL Working Group, 2013) Existem dois tipos de queries que podem ser feitas utilizando SPARQL, podendo estas serem de leitura ou de escrita. Os tipos de queries de leitura possíveis são “SELECT” que se assemelha ao SQL e devolve uma lista com os valores especificados no corpo da query, “CONSTRUCT” que devolve o resultado num grafo RDF, “DESCRIBE” que é uma variante do anterior e devolve o resultado num grafo RDF que descreve um conjunto de entidades e “ASK” que devolve o resultado à pergunta feita no corpo da query em booleano (sim ou não). Relativamente aos tipos de query de escrita, estas podem ser “CREATE” que cria um novo grafo vazio, “INSERT” que acrescenta frases RDF a um grafo existente, “COPY” que copia frases RDF de um grafo para outro, “ADD” que adiciona frases RDF a um grafo existente, “MOVE” que move frases RDF de um grafo para o outro, mas contrariamente ao “COPY” as frases são apagadas do grafo inicial, “DELETE” que remove a frase RDF especificada de um grafo, “CLEAR” que remove todas as frases RDF de um grafo e “DROP” que elimina completamente um grafo existente. De seguida serão apresentadas duas figuras com um exemplo de uma query de leitura, na Figura 12, e um exemplo de uma query de escrita, na Figura 13. Figura 12: Exemplo de uma query de leitura SELECT Figura 13: Exemplo de uma query de escrita INSERT Uma das suas variações, denominada por SPARQL Endpoint, permite receber e processar, numa rede HTTP, pedidos do Protocolo SPARQL. O Protocolo SPARQL consiste num protocolo baseado em HTTP que realiza dois tipos de operações, operações de leitura ou consulta e operações de atualização, tendo estes já sido explicados anteriormente. Neste, o cliente envia pedidos HTTP para os serviços do Protocolo SPARQL, que tratam desses pedidos e enviam a resposta HTTP para a origem. (Idehen, 2019; W3C, 2013b) 22 Esta é também considerada como uma das tecnologias chave da WS, e a sua versão atual é SPARQL 1.1, publicada em março de 2013, altura também em que se tornou uma recomendação W3C. (SPARQL Working Group, 2013; Wikimedia Foundation, 2021b) 3.1.4 Triplestore Um triplestore RDF consiste numa base de dados de grafo que armazena dados estruturados em triplos, sujeito – predicado – objeto, e consegue deduzir novas informações através das relações já existentes, permitindo a descoberta de relações ocultas. Estes dados podem ser considerados factos semânticos, e podem ser consultados através da linguagem SPARQL, permitindo assim fazer consultas complexas muito mais facilmente, e de forma mais rápida. Através deste é possível ligar dados, e quando enriquecidos com a sua análise, formam grafos de conhecimento extensos. Utiliza, também, Uniform Resource Identifier (URI), que se trata de um sistema de identificação única utilizado na Web, simplificando assim a partilha dos dados. E por isso é bastante utilizado em projetos Linked Data. (Ontotext, 2021) O seu nome advém da forma como os dados são estruturados, tal como referido anteriormente. Na Figura 14 é apresentado um exemplo da constituição de um triplestore. Alguns exemplos de triplestores são: • GraphDB; • OpenLink Virtuoso; • StarDog; • MarkLogic. Figura 14: Exemplo da constituição de um triplestore (Ontotext, 2021) 23 GraphDB O GraphDB é um triplestore capaz de derivar factos semânticos sobre dados existentes. Armazena dados sob a forma de triplos RDF, e tem uma grande capacidade de armazenamento. É um triplestore bastante utilizado, estando em 4º lugar nos triplestores mais populares, de acordo com a Wikipédia. (Ontotext, 2022; “Ontotext GraphDB,” 2022) Tem disponível 3 versões, sendo uma delas gratuita. A gratuita tem como principal diferença o seu armazenamento, que é menor, mas que mesmo assim tem capacidade para milhares de dados. OpenLink Virtuoso O OpenLink Virtuoso é a versão gratuita do Virtuoso Universal Server. Trata-se de uma base de dados que tem a capacidade de armazenar vários tipos de dados, incluindo triplos RDF. Tem uma alta capacidade de armazenamento e um alto desempenho e escalabilidade. Também permite fazer queries e armazenar dados utilizado SQL (Structured Query Language) e SPARQL. (OpenLink Software, 2019) A ontologia DBpedia utiliza o OpenLink Virtuoso para armazenar e publicar os seus dados RDF. (DBpedia Association, 2021) StarDog O StarDog Enterprise Knowledge Graph platform é uma base de dados que armazena dados de diferentes fontes e encontra uma conexão entre eles, utilizando machine learning. Utiliza normas criadas pelo W3C nos dados que resultam dessa conexão, normas essas que dizem respeito à representação de dados RDF. Os dados que recebe podem vir de bases de dados SQL e NoSQL. (Stardog Union, 2022) MarkLogic O software MarkLogic é uma base de dados expandida para armazenar triplos RDF, conseguindo gerir relações semânticas entre dados, e permitindo também a construção de grafos de conhecimento. A base de dados é NoSQL e tem capacidade para armazenar grandes quantidades de dados. (MarkLogic, 2022) Trata-se de um software pago, havendo a possibilidade de marcar uma live demo, em datas escolhidas pela empresa. (MarkLogic, 2022) 24 3.2 CIDOC CRM CIDOC CRM refere-se à ontologia denominada por Conceptual Reference Model (CRM), e foi desenvolvida, durante 8 anos, por peritos de diversas áreas com o apoio do Comité Internacional de Documentação do Conselho Internacional de Museus (CIDOC). Esta é uma ontologia formal, utilizada para a integração de informação relacionada com o domínio do património cultural, arquivos e bibliotecas. O CIDOC CRM consegue ajudar investigadores na pesquisa de questões complexas sobre a antiguidade, e permite relacionar dados que à primeira vista seriam incompatíveis. Isto tudo é possível através da estruturação de dados de modo formal, e do fornecimento de descrições dos seus vários conceitos, que permite a integração de dados de diferentes origens, tal como falado anteriormente, e também a troca de informação. Esta ontologia fornece classes e relações básicas sobre vários aspetos do património cultural, arquivos e bibliotecas, sendo para isso necessária a criação de extensões para aspetos mais complexos e de forma a suportar diferentes tipos de questões especializadas. Estas extensões são criadas em conjuntos com comunidades de investigação. Na Figura 15 é apresentada uma parte da hierarquia das suas classes. A razão pela qual foi optada a apresentação de uma parte da hierarquia desta ontologia é esta possuir um grande número de classes (81 classes) e por isso a figura tornar-se-ia bastante extensa e impercetível. (Doerr, 2005; Matter & Haslhofer, 2007; SIG, 2014) Figura 15: Parte da hierarquia de Classes CIDOC CRM (Matter & Haslhofer, 2007) 25 Como se pode verificar na Figura 15, a classe principal desta ontologia é a E1 CRM Entity, esta é uma classe que compreende todos os objetos compreendidos no CIDOC CRM. Esta é constituída por sete subclasses, estando representadas na figura cinco delas. Estas subclasses são E2 Temporal Entity onde estão compreendidos todos os fenómenos, a E52 Time-Span que compreende extensões de tempo que têm ínicio, meio e fim, a E53 Place que compreende extensões de espaço natural da Terra, a E54 Dimension que compreende propriedades que são quantificáveis, a E59 Primitive Value que compreende valores de dados do tipo primitivos relativos a bases de dados ou linguagens de programação, a E77 Persistent Item que compreende entidades físicas ou conceptuais, e por fim a E92 Spacetime Volume que compreende conjuntos de pontos em 4 dimensões no espaço-tempo físico. Estas subclasses têm também as suas próprias subclasses que estão diretamente relacionadas a si. Algumas dessas podem ser observadas na Figura 15. (Bekiari et al., 2021) Para além das suas 81 classes, esta também possui 160 propriedades, que estão relacionadas com as diversas classes. Destas propriedades, as que poderão ser interessantes ao projeto, tendo em conta os atributos da base de dados são, P1_is_identified_by, P2_has_type, P3_has_note, P32_used_general_technique, P44_has_condition, P56_bears_feature, P65_shows_visual_item e P90_has_value. Para finalizar, em dezembro de 2006 foi reconhecida como uma norma ISO, tendo sido renovado o seu estatuto em 2014, e a sua denominação é ISO21127. (SIG, 2014) 26 3.3 DBpedia DBpedia trata-se de um projeto, iniciado em 2007, que extrai informação estruturada da Wikipédia e a torna disponível na Web como Linked Data. Baseia-se na ideia de extrair uma base de conhecimento estruturada, da informação não estruturada que está disponível na Wikipédia. (DBpedia Association, 2021) O projeto DBpedia possibilita a consulta da informação extraída utilizando, por exemplo, SPARQL, que é uma linguagem de consulta padrão para a Web Semântica. Isto permite aos utilizadores fazer perguntas sobre a informação que está disponível, e obter respostas de forma legível por máquina. Tem uma vantagem relativamente a outras bases de conhecimento, pois cobre várias áreas de conhecimento. E, ao recolher dados da Wikipédia, permite responder a questões complexas. Utiliza o triplestore OpenLink Virtuoso para armazenar a sua informação e de forma a tornála pública, tal como referido no Ponto 3.1.4. 3.3.1 DBpedia ontology A ontologia DBpedia, criada em 2008, é um modelo formal dos conceitos e relações que são descritos na Wikipédia. Esta ontologia, expressa em OWL, é utilizada para fornecer uma forma consistente e padronizada de representar os conceitos e relações da Wikipédia de forma legível por máquina, e é constantemente atualizada com contribuições da comunidade DBpedia. (DBpedia Association, 2021) Atualmente esta ontologia conta com 768 classes, estando em destaque as classes Place, Person, Work, Species, Organisation e Other. Todas estas classes são compostas por diveras propriedades distintas, dando uma totalidade de 4 828 418 instâncias. Tendo tudo isto em conta, é percetível o porquê de este projeto ser um dos mais utilizados para o enriquecimento e interoperabilidade dos dados. 33 Ontologia MAO/TAO A ontologia MAO/TAO 7 foi criada para descrever e indexar materiais de museus e artes, sendo uma junção da ontologia MAO com a TAO, onde a MAO se relaciona com os materiais de museus e a TAO com design e comunicação. E foi publicada pela National Library of Finland em 2004. Nos anos 2015 e 2019 foram criados projetos para expandir esta ontologia de forma a compreender um maior número de conceitos, em 2015 o objetivo passou pela adição de 800 conceitos novos, e em 2019 o objetivo passou pela adição de 1000 conceitos novos relacionados com achados de moedas e objetos arqueológicos provenientes da Idade da Pedra e da Idade do Ferro, dando assim um total de 1800 novos conceitos adicionados desde a sua criação. Ao longo destes anos foram também analisados e atualizados alguns dos conceitos originais da sua primeira versão. Esta atualização foi realizada também de forma a corresponder à estrutura da ontologia geral da Finlândia (YSO). Com isto é observável que esta ontologia conta com aproximadamente 13 500 conceitos, estando estes representados em finlandês. A hierarquia das suas classes, tal como observada nas Figuras 16 a 18, é composta por 2 classes principais, sendo estas Events and action que tal como o nome indica, compreende eventos e ações que podem ocorrer e Objects que compreende todo o tipo de objetos. Nas Properties, visível na Figura 18, compreende as propriedades dos objetos, eventos e ações. A classe Events and action é constituída por quatro subclasses, a classe Objects por cinco subclasses e a Properties apresenta 235 propriedades principais, havendo propriedades compreendidas dentro dessas. (Finto, 2021; The Finnish Terminology Centre, 2016, 2020) Figura 16: Parte da Hierarquia de classes da ontologia MAO/TAO (Events and action) (Finto, 2021) 7 https://finto.fi/maotao/en/ 34 Figura 17: Parte da Hierarquia de classes da ontologia MAO/TAO (Objects) (Finto, 2021) Figura 18: Parte da Hierarquia de classes da ontologia MAO/TAO (Properties) (Finto, 2021) Foi feita uma avaliação do protótipo deste projeto que revelou que a plataforma melhora a recolha de dados arqueológicos e facilita todo esse processo. E, com a interoperabilidade com outras bases de dados existentes de património cultural, proporcionarão uma maior facilidade nas investigações futuras, e uma melhoria da acessibilidade e disponibilidade de dados. Em suma, este projeto vem facilitar os processos de criação de relatórios e pesquisa de locais de investigação e estabelecer a interoperabilidade com bases de dados de recursos arqueológicos internacionais. (Hassanzadeh et al., 2020) 35 3.4.4 ZooarchNet O projeto ZooarchNet tem como objetivo a combinação de dados biológicos e dados culturais, e a integração de registos zooarqueológicos nesses dados, de forma a colmatar lacunas que estão presentes entre essas áreas. E para isso, aproveita a plataforma já existente de biodiversidade da VertNet 8 , visto esta não ter capacidades para se tornar num LOD. A VertNet é um projeto colaborativo que disponibiliza dados sobre biodiversidade na web livremente, que tem como objetivo tornar estes dados fáceis de encontrar, publicar e utilizar, e é baseado em computação em cloud. (VertNet, 2016) Este é um projeto LOD que acomoda dados zooarqueológicos de várias fontes, e que assegura a apresentação correta dos metadados de cada objeto que nele estão presentes. Adicionalmente, este permite a interoperabilidade dos dados, e enfatiza a importância dos identificadores que permitem e facilitam a descoberta de dados entre áreas. Desta forma, destina-se a ser usado como forma a responder a necessidades da atualidade e futuras, na área da investigação do impacto do ser humano na biodiversidade animal. • Como funciona? Este projeto utiliza o padrão de dados Darwin Core para descrever os dados zooarqueológicos que o constituem, e utiliza também conteúdo descritivo adicional específico de cada espécie. (LeFebvre et al., 2019) Ontologia Darwin Core A ontologia Darwin Core consiste num conjunto de termos, com a sua semântica bem definida, relacionados com biodiversidade, e foi confirmada como padrão em outubro de 2009. É uma ontologia que utiliza RDF e o seu objetivo principal passa pela criação de uma linguagem comum de partilha de dados sobre biodiversidade, este tem sido um desafio devido à existência de diversos conceitos e normas sobre esta área espalhados pelas diversas instituições. Por forma a alcançar esse objetivo esta define termos de forma simples e cria uma relação entre estes. Com a sua utilização é expectável que se consiga superar a limitação de disponibilidade de dados sobre biodiversidade e que se consiga suprir as necessidades de investigação desta 8 http://vertnet.org/ 36 área. Isto deve-se ao facto de que esta ontologia aumenta o valor de dados sobre biodiversidade e proporciona a sua reutilização, dados estes que estão disponíveis abertamente na web. Os seus termos estão organizados em nove classes principais, essas classes podem ser observadas na Figura 19. (Wieczorek et al., 2012) Figura 19: Classes Principais do Darwin Core (Wieczorek et al., 2012) As primeiras sete classes estão relacionadas com aspetos gerais da biodiversidade e as duas restantes estão relacionadas com conceitos que necessitam de uma estrutura de dados complexa. Relativamente às primeiras sete classes estas são, a classe “Record-level” que contém termos que podem ser aplicados a qualquer tipo de dados, a classe “Occurrence” que aborda a existência de um organismo num determinado lugar e tempo, a classe “Event” que aborda uma ação que ocorre nalgum local num determinado período de tempo, a classe “Location” que aborda um local ou área, a classe “Identification” que aborda uma determinação taxonómica, a classe “Taxon” que aborda um grupo de organismos que são considerados uma unidade homogénea e a classe “GeologicalContext” que aborda informação geológica, como por exemplo a estratigrafia de um local. Em relação às duas últimas classes, estas consistem na classe “ResourceRelationship” que aborda uma relação de um “rdfs:Resource” com outro e a classe “MeasurementOrFact” que aborda uma medida ou facto sobre um “rdfs:Resource”. (TDWG, 2021) 37 3.4.5 Europeana Data Model O Europeana Data Model (EDM) é um modelo que tem como objetivo suportar a recolha, ligações e enriquecimento de dados culturais da Europa. Este projeto veio facilitar a entrada da Europeana na Web Semântica, sendo esta Open Data e interoperável com outros LD. Este modelo resultou da necessidade de contornar as limitações do antigo modelo Europeana Semantic Elements (ESE) na inserção da Europeana no “mundo” LOD. Uma destas limitações passa pelo ESE não permitir a inclusão de ligações a recursos web externos, sendo este um dos grandes fatores de um LOD. O EDM veio oferecer uma maior flexibilidade e expressividade em relação ao ESE e veio permitir representar os milhões de objetos de património cultural, presentes na Europeana, semanticamente e de forma mais rica. Para isso baseia-se em normas estabelecidas, como por exemplo RDF e SKOS, e atua como uma ontologia comum de alto nível, permitindo a interoperabilidade. Esta interoperabilidade leva a um enriquecimento dos dados, dando possibilidade de os tornar mais complexos ao permitir que sejam associados com outros que estejam relacionados. (Doerr et al., 2010) Este projeto utiliza um conjunto de elementos bem definidos para o seu bom funcionamento, estes variam de elementos introduzidos por eles mesmos e elementos reutilizados de outros namespaces, isto vem permitir que os objetos tenham descrições mais completas e também preservar o valor proveniente desses namespaces utilizados pela comunidade. Estes namespaces são: • Dublin Core; • Resource Description Framework (RDF) e a RDF Schema (RDFS); • Simple Knowledge Organization System (SKOS); • OAI Object Reuse and Exchange (ORE); • W3C Data Catalog Vocabulary (DCAT); • Creative Commons (CC); • SIOC Services Ontology Module. 38 O EDM também inclui classes do CIDOC CRM que são utilizadas para relacionar com as suas de forma aumentar a sua riqueza. Como exemplo é mostrada a classe “edm:Agent” na Figura 20, aqui podemos verificar que a classe equivalente no CIDOC CRM é a “E39_Actor”. Olhando para a Figura 21, onde é mostrada a classe “E39_Actor”, podemos verificar que a definição é exatamente a mesma nas duas classes. Por isso é certo afirmar que a classe do EDM, mesmo tendo um nome distinto, está totalmente relacionada com a classe do CIDOC CRM. (Europeana, 2014, 2017) Figura 20: Exemplo Classe EDM - Classe "edm:Agent"(Europeana, 2017) Figura 21: Classe do CIDOC CRM "E39_Actor"(Bekiari et al., 2021) Olhando agora para a sua hierarquia de classes, e tendo em conta a Figura 22, as classes assinaladas a branco são as classes que foram acolhidas de outras ontologias estando identificadas quais são essas ontologias antes do seu nome. É exemplo disso a “ore:Proxy” que se trata da classe Proxy proveniente da ontologia ORE, a “skos:Concept” que se trata da classe Concept proveniente da ontologia SKOS, a “dcmitype:Collection” que se trata da classe Collection proveniente da ontologia Dublin Core, a “dcat:Dataset” que se trata da classe Dataset proveniente da ontologia DCAT, e por fim, a “cc:License” que se trata da classe License proveniente da ontologia CC. As classes sinalizadas a azul são as classes introduzidas pelo EDM, e olhando para as principais, as que não são subclasses de nenhuma classe, estas são a 39 “edm:EuropeanaObject” que iclui qualquer objeto que é resultante das atividades da Europeana, a “edm:InformationResource” que inclui um recurso de informação, a “edm:NonInformationResource” que inclui todos os recursos que não são recursos de informação e a “edm:ProvidedCHO” que inclui todos os objetos de Herança Cultural que a Europeana coleta descrições sobre. (Europeana, 2017) Figura 22: Hierarquia de classes EDM (Europeana, 2017; Silva et al., 2019) Este conjunto de classes, incluindo as que são provenientes de outras ontologias, permitem que os dados sejam estruturados sem que seja perdida a riqueza destes. (Silva et al., 2019) Por fim, falando das suas propriedades, o EDM possui 3 propriedades provenientes da ontologia ORE, 37 propriedades provenientes da ontologia Dublin Core e 39 propriedades próprias introduzidas pelo EDM. Parte destas propriedades estão representadas na Figura 23. Figura 23: Hierarquia de propriedades EDM (Europeana, 2017) 40 As propriedades do EDM, à semelhança das classes, também se podem relacionar com as do CIDOC CRM. Um exemplo disso é a propriedade “edm:isSimilarTo”, presente na Figura 24, e a propriedade “P130_shows_features_of” do CIDOC, na Figura 25. Figura 24: Propriedade EDM "edm:isSimilarTo" (Europeana, 2017) Figura 25: Propriedade CIDOC CRM "P130_shows_features_of" Ao contrário do exemplo da equivalência das classes, estas não têm descrições iguais, mas podemos verificar que são bastante semelhantes e por isso faz sentido estarem relacionadas. 41 4. PROCEDIMENTOS METODOLÓGICOS Neste capítulo serão apresentados os diversos procedimentos metodológicos utilizados neste projeto. Numa primeira fase, de pesquisa, foi utilizado o Design Science Research. Foi adicionalmente feita uma investigação sobre os métodos Dublin Core Tabular Application Profile (DCTAP), e sobre o Me4MAP, estes métodos são importantes para a definição da estruturação dos dados, sendo dado enfâse no método DCTAP, visto ser o método a utilizar no desenvolvimento deste projeto. 4.1 Design Science Research Neste projeto será utilizado o Design Science Research (DSR). Trata-se de uma framework metodológica que se preocupa com a resolução de problemas de forma a aumentar conhecimento tecnológico e científico. Este conhecimento é adquirido através da criação de artefactos inovadores, e do Design Knowlegde (DK) gerado. Nesta área de Sistemas de Informação (SI), o DK pode por exemplo, incluir os conhecimentos necessários sobre como modelar processos de negócio ou até mesmo os necessários para saber como alinhar os SI com a estratégia da organização, entre outros. (Brocke et al., 2020) Este é constituído por três ciclos distintos, sendo estes o Relevance Cycle, o Rigor Cycle e por fim, o Design Cycle, tal como se pode observar na Figura 26. Figura 26: Ciclos do DSR (Hevner, 2007) 42 O Relevance Cycle consiste no ciclo onde é iniciada a investigação, aqui são levantados os requisitos necessários à realização deste projeto e quais os critérios de aceitação serão utilizados para a avaliação do seu resultado final. Aqui poderão ser realizados testes de campo de forma a avaliar a relevância da investigação e verificar se será necessário realizar passos adicionais deste ciclo ou alterar requisitos. É aqui que, através da revisão de literatura efetuada até ao momento, é mostrada a pertinência desta investigação, é também feito o estudo do domínio de aplicação. Em relação ao Rigor Cycle, este foca-se na base de conhecimento da investigação. É aqui que é explorado e analisado o estado da arte dos projetos que se relacionam com o que está a ser desenvolvido, onde é desenvolvida toda a base de conhecimento necessária para a sua compreensão, e onde são escolhidos os métodos apropriados a utilizar no desenvolvimento. É aqui importante demonstrar onde é que o projeto inova em relação aos restantes que podem já existir. Uma boa fundamentação teórica é um grande passo para que a investigação não seja rejeitada. Este ciclo, em relação aos milestones definidos para este projeto, corresponde à revisão de leitura, que foi efetuada para este documento, o aprofundamento dos fundamentos teóricos, e à definição dos métodos de investigação. (Hevner, 2007) Por fim, o Design Cycle, corresponde à fase de desenvolvimento dos artefactos da investigação, à sua avaliação e feedback. Este é o ponto fulcral de qualquer projeto de investigação, pois é neste ponto que são utilizados os requisitos definidos no Relevance Cycle e os métodos escolhidos no Rigor Cycle, de forma a desenvolver o processo de investigação e artefactos associados. Um ponto importante a ter em consideração neste ciclo, é que é necessário manter o equilíbrio entre o esforço posto no desenvolvimento dos artefactos e o posto na sua avaliação. Em relação às tarefas definidas para este projeto, corresponde ao desenvolvimento do perfil de aplicação, desenvolvimento de mecanismos de recolha, processamento, publicação e visualização dos dados, desenvolvimento de uma prova de conceito que inclua esses mecanismos e a validação do protótipo desenvolvido. (Hevner, 2007) 49 também está diretamente relacionada com a anterior, e é aqui referido o tipo das restrições, se aplicável, valueShape onde aqui, caso haja necessidade, se poderá mencionar a classe correspondente, e por fim a note onde permite que o autor da tabela possa deixar as suas notas caso ache necessário. Neste projeto foi utilizado o DCTAP, podendo este ser observado na Tabela 4 da Secção 5.1. O DCTAP é bastante importante para este projeto, na medida em que servirá de base para a criação do Perfil de Aplicação, que será utilizado como guia para o código RDF e para os templates ShEx. Por isso é correto dizer que este é um dos pontos fulcrais de todo o projeto. 50 5. DESENVOLVIMENTO DO METADATA APPLICATION PROFILE Para que se pudesse transformar os dados de forma a se tornarem semanticamente interoperáveis, era necessário encontrar propriedades e classes que se relacionassem com as tabelas e atributos utilizados neste projeto. De forma a facilitar esse processo foi utilizado um documento Excel, tal como mencionado na Secção ‘Análise e escolha dos conceitos’. Foi então construída uma tabela de forma a identificar quais as melhores propriedades e classes encontradas e quais as que seria necessário criar. Para isso foi utilizado o LOV (Linked Open Vocabularies) como ajuda para a procura destas, e no DBpedia, através de SPARQL Endpoint 9 , foi utilizada uma query de forma a encontrar todas as propriedades existentes, podendo ser visualizada na Figura 28. Visto a tabela Motivo Cena ser composta por identificadores de outras tabelas, e estes não serem utilizados neste processo, esta tabela não estará presente no documento. A versão final do documento pode ser observada nas Figuras 29 a 33. Figura 28: Query utilizada no DBpedia para a procura de propriedades 9 https://dbpedia.org/sparql/ 51 Figura 29: Tabela Excel do Sitio/Núcleo Figura 30: Tabela Excel do Afloramento 52 Figura 31: Tabela Excel do Motivo Figura 32: Tabela Excel da Parte Representada Figura 33: Tabela Excel da Cena 53 5.1 Dublin Core Tabular Application Profile Um ponto bastante importante antes de se criar um perfil de aplicação, é a procura de esquemas de classes e propriedades, de forma a encontrar as que podem ser relacionadas com os atributos do projeto. Para isso é feita uma pesquisa dos esquemas existentes e é feito um estudo sobre quais têm prioridade sobre as restantes. De seguida será explicada a prioridade dada aos esquemas selecionados e as razões. Primeiramente, foi dada prioridade ao esquema CIDOC CRM, tentando sempre utilizar propriedades onde o seu significado e nome fizessem sentido e fossem percetíveis tanto para humanos como para máquinas. Algumas propriedades do CIDOC CRM poderiam ser utilizadas, mas como o seu nome não permitia perceber qual o atributo a que se referia, foi decidido não as utilizar. A razão pela qual foi dada prioridade a este esquema deve-se a este ser um dos requisitos intrínsecos ao projeto. Uma das propriedades selecionadas deste esquema é a P1_is_identified_by que é utilizada para representar o número de inventário de um objeto. Aos atributos em que não existem propriedades do CIDOC CRM que se relacionem e que encaixam nestes critérios, foi dada preferência ao esquema DCMI Metadata Terms, sendo este um esquema conceituado, e por isso é bastante relevante a sua utilização nas propriedades que possam se relacionar, uma das propriedades escolhidas é a identifier para representar o identificador da base de dados da UAUM. Visto este esquema, DCMI Metadata Terms, não ter muitas propriedades que se relacionem com esta área do projeto, foi dada uma preferência adicional à DBpedia e ao Schema.org, sendo que a DBpedia teve prioridade sobre o Schema.org. Tendo em conta que a DBpedia abrange mais áreas de conhecimento, fez mais sentido dar prioridade sobre o Schema.org, já que abrange menos áreas. A propriedade utilizada do Schema.org é a color. Relativamente à DBpedia, existem dois esquemas de propriedades, o esquema em que as propriedades estão bem documentadas e são bastante específicas, DBpedia ontology, e o em que as propriedades são retiradas da Wikipédia, e, portanto, são mais gerais, DBpedia property. Foi dada preferência à DBpedia ontology, visto as suas propriedades estarem melhor documentadas. Mas como este possui menos propriedades, criou-se a necessidade de utilização da DBpedia property. Um exemplo do DBpedia ontology é a propriedade name, esta 54 também existe na DBpedia property mas foi escolhida a versão da DBpedia ontology pela razão dita em cima. E um exemplo da DBpedia property é a propriedade altitude. No final, depois de encontradas as propriedades nestes namespaces, restaram alguns atributos aos quais não foi encontrada uma propriedade à qual se relacionasse, tornando-se assim necessária a criação dessas propriedades, identificadas por raraa, que é o nome do proejto ao qual esta dissertação está relacionada. Um exemplo é a propriedade para o atributo Patine, onde a encontrada, no namespace MAO/TAO não tem uma etiqueta que seja percetível, p8305, e por isso será criada uma que seja subpropriedade desta. Durante a criação das propriedades, houve o cuidado de relacioná-las com outras já existentes. Depois de definidas os esquemas a utilizar, foi necessária a criação de uma tabela com os prefixos que seriam utilizados, de forma a não ser necessário utilizar todo o URL quando se menciona uma propriedade ou classe. Na Tabela 2 podemos então verificar todos os prefixos úteis a este projeto. Tabela 2: Tabela dos prefixos utilizados no DCTAP Prefix URL schema https://schema.org/ dct http://purl.org/dc/terms/ cidoc http://cidoc-crm.org/cidoc-crm/7.1.1/ ao http://ariadne-infrastructure.eu/ns/ dbo https://dbpedia.org/ontology/ dbp https://dbpedia.org/property/ raraa http://linkclassespropriedades.com/property# (URL exemplo temporário) rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# Com a tabela dos prefixos definida, pode-se apresentar a Tabela 3 onde são mostrados os atributos que são utilizados neste projeto, a sua propriedade correspondente e uma descrição da propriedade. Ao todo foram selecionadas 56 propriedades distintas para este projeto, sendo algumas destas criadas para o propósito deste. Contando as que foram reutilizadas, estas dão um total de 77 propriedades, estando distribuídas pelas 5 classes definidas, tendo em conta as tabelas da base de dados da UAUM. O Sítio/Núcleo possui 18 propriedades, o Afloramento possui 21 propriedades, o Motivo possui 20 propriedades, a Parte Representada possui 12 propriedades, e por fim, a Cena possui 6 propriedades. 55 Tabela 3: Atributos, Propriedades correspondentes e a explicação de escolha Atributo Propriedade Descrição Sítio/Núcleo Nome dbo:name Nome de um objeto. Topónimo dbp:placename Topónimo do sítio onde um objeto se encontra. Conservação dbp:conservation Estado de conservação de um objeto. Descrição dct:description “Um relato do recurso. A descrição pode incluir mas não está limitada a: um resumo, um índice, uma representação gráfica, ou uma conta de texto livre do recurso.” Interpretação raraa:interpretation “Interpretação de um Sítio ou Núcleo.” Classificação dbo:classification “Qualquer string representando uma classe ou categoria a que esta coisa esteja atribuída.” Código Classificação dbo:code “Superpropriedade para qualquer designação (string, inteiro como string) que se destina a identificar uma entidade dentro do contexto de um sistema.” Área dbo:área “A área da coisa em metros quadrados.” Lugar dbo:place “Relaciona uma entidade com o local povoado em que se encontra.” Concelho dbo:municipality Concelho onde se localiza um objeto. Freguesia dbo:parish Freguesia onde um objeto está localizado. 56 Atributo Propriedade Descrição Coordenadas X ao:has_longitude “Esta propriedade indica o valor mínimo de longitude das coordenadas de uma Região_Espaço_AO.” Coordenadas Y ao:has_latitude “Esta propriedade indica o valor da latitude das coordenadas de uma Região_Espacial_AO.” Coordenadas Z dbp:altitude Altitude onde um objeto se encontra. Acessos dbo:access Acessos para um objeto. Tipo – Acesso raraa:accessType “Tipo de acessos de um sítio ou núcleo.” Observações cidoc:P3_has_note “Esta propriedade é um recipiente para todas as descrições informais sobre um objecto que não tenham sido expressas em termos de construções CIDOC CRM.” Identificador dct:identifier “Uma referência inequívoca ao recurso dentro de um determinado contexto.” Afloramento Número de Inventário cidoc:P1_is_identified_by “Esta propriedade descreve a designação ou identificação de qualquer item do mundo real por um nome ou qualquer outro identificador.” Descrição dct:description “Um relato do recurso. A descrição pode incluir mas não está limitada a: um resumo, um índice, uma representação gráfica, ou uma conta de texto livre do recurso.” 57 Atributo Propriedade Descrição Coordenadas X ao:has_longitude “Esta propriedade indica o valor mínimo de longitude das coordenadas de uma Região_Espaço_AO.” Coordenadas Y ao:has_latitude “Esta propriedade indica o valor da latitude das coordenadas de uma Região_Espacial_AO.” Coordenadas Z dbp:altitude Altitude onde um objeto se encontra. Tipo de Suporte dbo:type Tipo de suporte geológico de um objeto. Litologia dbp:lithology Litologia de um objeto. Formação Litológica raraa:lithologicalFormation “Local onde se encontram as rochas.” Cor schema:color “A cor do produto.” Conservação dbp:conservation Estado de conservação de um objeto. Morfologia – Superfície dbp:morphology Morfologia de um objeto. Aspeto – Superfície dbp:appearance Aspeto de um objeto. Termo de Alteração cidoc:P44_has_condition “Esta propriedade regista um Estado de Condição E3 para alguma Coisa Física E18.” Direção dbp:direction Direção de um objeto. Inclinação dbp:inclination Inclinação de um objeto. Estratigrafia – Inclinação dbp:stratigraphy Estratigrafia de um objeto. Comprimento dbo:length Comprimento de um objeto. Altura schema:height “A altura do item.” Observações cidoc:P3_has_note “Esta propriedade é um recipiente para todas as descrições informais sobre um objecto que não tenham sido expressas em termos de construções CIDOC CRM.” 58 Atributo Propriedade Descrição Identificador dct:identifier “Uma referência inequívoca ao recurso dentro de um determinado contexto.” Sítio/Núcleo cidoc:P46i_forms_part_of “Esta propriedade associa uma instância de Coisa Física E18 com outra instância de Coisa Física que faz parte dela. A extensão espacial da parte que compõe está incluída na extensão espacial do todo.” Motivo Número de Inventário cidoc:P1_is_identified_by “Esta propriedade descreve a designação ou identificação de qualquer item do mundo real por um nome ou qualquer outro identificador.” Descrição dct:description “Um relato do recurso. A descrição pode incluir mas não está limitada a: um resumo, um índice, uma representação gráfica, ou uma conta de texto livre do recurso.” Conservação dbp:conservation Estado de conservação de um objeto. Cronologia dct:coverage “O tópico espacial ou temporal do recurso, aplicabilidade espacial do recurso, ou jurisdição sob a qual o recurso é relevante.” Estilo dbo:style Estilo de um objeto. Técnica dbo:technique Técnica utilizada numa pintura. Técnica-Variante cidoc:P32_used_general_technique “Esta propriedade identifica a técnica ou método, modelado como uma instância do Tipo E55, 65 shape ID Property ID Mandatory Repeatable Value Node Type Value Data Type Value Constraint Type dbp:conservation FALSE FALSE IRI VC*: Conservação dbp:morphology FALSE FALSE IRI VC*: Morfologia superfície dbp:appearance FALSE FALSE IRI VC*: Aspeto Superfície cidoc:P44_has_ condition FALSE FALSE Literal xsd:string dbp:direction FALSE FALSE Literal xsd:string dbp:inclination FALSE FALSE Literal xsd:float dbp:stratigraphy FALSE FALSE Literal xsd:string dbo:length FALSE FALSE Literal xsd:float schema:height FALSE FALSE Literal xsd:float cidoc:P3_has_note FALSE FALSE Literal xsd:string dct:identifier TRUE FALSE IRI cidoc:P46i_forms_ part_of FALSE TRUE IRI parte_re presenta da rdf:type TRUE TRUE IRI raraa:represented Part FALSE FALSE IRI VC*: Parte Representada (Tipo) dbp:shape FALSE FALSE IRI VC*: Subtipo 66 shape ID Property ID Mandatory Repeatable Value Node Type Value Data Type Value Constraint Type cidoc:P57_has_nu mber_of_parts FALSE FALSE Literal xsd:intege r dbo:position FALSE FALSE Literal xsd:float raraa:perspective FALSE FALSE Literal xsd:string dbo:technique FALSE FALSE Literal xsd:string cidoc:P32_used_g eneral_technique FALSE FALSE Literal xsd:string dbp:animation FALSE FALSE Literal xsd:string schema:height FALSE FALSE Literal xsd:float schema:width FALSE FALSE Literal xsd:float dct:identifier TRUE FALSE IRI cidoc:P46i_forms_ part_of FALSE TRUE IRI Cena rdf:type TRUE TRUE IRI cidoc:P1_is_identif ied_by FALSE FALSE Literal xsd:string dbo:name FALSE FALSE Literal xsd:string dct:description FALSE FALSE Literal xsd:string dct:identifier TRUE FALSE IRI cidoc:P46i_forms_ part_of FALSE TRUE IRI cidoc:P46_is_com posed_of FALSE TRUE IRI VC*- Vocabulário Controlado. Os vocubalários controlados codificados estão apresentados na Secção 5.3, e no Anexo A podem ser consultados os seus conjuntos de valores possíveis. 67 De forma a relacionar os recursos, foram utilizadas as propriedades do CIDOC CRM P46i_forms_part_of e P46_is_composed_of, onde a primeira identifica os objetos aos quais o objeto que a possui, forma parte de, e a segunda identifica os objetos pelos quais o objeto que a possui, é composto. Tirando o Sítio/Núcleo, os restantes têm a propriedade P46i_forms_part_of que identifica o objeto ao qual este faz parte. O único que utiliza a propriedade P46_is_composed_of é a Cena, que graças à tabela da base de dados Motivo Cena, são identificados os Motivos que cada Cena possui. Como cada Motivo terá um URL correspondente, foi tomada a decisão de identificar na Cena os Motivos que lhe pertencem, e não o contrário. Para a identificação de cada objeto, foi utilizada a propriedade identifier do DCMI Metadata Terms. A decisão de se usar esta propriedade em vez da propriedade do CIDOC CRM P1_is_identified_by, deve-se ao facto da propriedade do CIDOC já ser utilizada para o atributo Número de Inventário. Com isto foram atribuídas ambas as propriedades aos atributos que melhor se adequavam. De seguida serão demonstrados exemplos de código RDF relativos a cada tipo de dados que estão presentes na base de dados da UAUM. Este código foi desenvolvido tendo em conta o perfil de aplicação apresentado anteriormente. Tendo em conta as propriedades definidas foi possível definir que dados se relacionavam com cada propriedade, dando-lhes assim um maior valor semântico. Através desse código, e com a ajuda da ferramente W3C RDF Validation Service 11 , foi possível originar grafos de forma a poder observar a sua estrutura de uma forma mais percetível para o utilizador. Serão agora apresentados, para os dados de cada tabela da base de dados, um exemplo de conjunto de dados codificado em RDF e o grafo que foi originado através dele. 11 https://www.w3.org/RDF/Validator/ 68 5.1.1 Sítio/Núcleo Código RDF <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:dbo="http://dbpedia.org/ontology/" xmlns:schema="http://schema.org/" xmlns:dbp="http://dbpedia.org/property/" xmlns:dct="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cidoc="http://cidoc-crm.org/cidoc-crm/7.1.1/" xmlns:ao="http://ariadne-infrastructure.eu/ns/" xmlns:raraa="http://linkclassespropriedades.com/property#"> <rdf:Description rdf:ID="SN4-1"> <rdf:type rdf:resource="http://cidoc-crm.org/cidoc-crm/7.1.1/E27_Site"/> <dbo:name>Alto das Malhadas - Escavação</dbo:name> <cidoc:P2_has_type>Escavação</cidoc:P2_has_type> <ao:has_longitude>0,000000</ao:has_longitude> <ao:has_latitude>0,000000</ao:has_latitude> <dct:identifier rdf:resource="https://linkdositionucleo.com/#4-1"/> </rdf:Description> </rdf:RDF> Grafo RDF Figura 34: Grafo resultante da classe Sítio/Núcleo 69 5.1.2 Afloramento Código RDF <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:dbo="http://dbpedia.org/ontology/" xmlns:schema="http://schema.org/" xmlns:dbp="http://dbpedia.org/property/" xmlns:dct="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cidoc="http://cidoc-crm.org/cidoc-crm/7.1.1/" xmlns:ao="http://ariadne-infrastructure.eu/ns/" xmlns:raraa="http://linkclassespropriedades.com/property#"> <rdf:Description rdf:ID="Af3"> <rdf:type rdf:resource="http://linkclassespropriedades.com/class#outcrop"/> <cidoc:P1_is_identified_by>VRM001</cidoc:P1_is_identified_by> <ao:has_longitude>0,000000</ao:has_longitude> <ao:has_latitude>0,000000</ao:has_latitude> <dbp:altitude>0,000000</dbp:altitude> <dbo:type rdf:resource="https://linkvocabcontrolado.com/Af/#Xistosidade"/> <dbp:lithology rdf:resource="https://linkvocabcontrolado.com/Af/#Xisto"/> <raraa:lithologicalFormation rdf:resource="https://linkvocabcontrolado.com/Af/#Desejosa"/> <dbp:conservation rdf:resource="https://linkvocabcontrolado.com/Af/#Completa"/> <dbp:morphology rdf:resource="https://linkvocabcontrolado.com/Af/#Plana"/> <dbp:appearance rdf:resource="https://linkvocabcontrolado.com/Af/#Acidentada"/> <cidoc:P44_has_condition>Sim</cidoc:P44_has_condition> <dbp:inclination>Horizontal</dbp:inclination> <dbp:stratigraphy>NE (Nordeste)</dbp:stratigraphy> <dct:identifier rdf:resource="Af3"/> <cidoc:P46i_forms_part_of rdf:resource="https://linkdositionucleo.com/#2091-2091"/> </rdf:Description> </rdf:RDF> 70 Grafo RDF Figura 35: Grafo resultante da classe Afloramento 5.1.3 Motivo Código RDF <?xml version="1.0"?> <rdf:RDF xmlns:dbo="http://dbpedia.org/ontology/" xmlns:schema="http://schema.org/" xmlns:dbp="http://dbpedia.org/property/" xmlns:dct="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cidoc="http://cidoc-crm.org/cidoc-crm/7.1.1/" xmlns:ao="http://ariadne-infrastructure.eu/ns/" xmlns:raraa="http://linkclassespropriedades.com/property#"> <rdf:Description rdf:about="https://doi.org/10.5281/zenodo.6963462"> <rdf:type rdf:resource="http://cidoc-crm.org/cidoccrm/7.1.1/E29_Design_or_Procedure"/> <cidoc:P1_is_identified_by>VRM003-004</cidoc:P1_is_identified_by> 71 <dct:description>Espada embainhada na cintura de cavaleiro.</dct:description> <dct:coverage rdf:resource="https://linkvocabcontrolado.com/Mt/#Idade_do_Ferro"/> <dbp:conservation rdf:resource="https://linkvocabcontrolado.com/Mt/#Bom"/> <dbo:style rdf:resource="https://linkvocabcontrolado.com/Mt/#Estilizado"/> <cidoc:P32_used_general_technique rdf:resource="https://linkvocabcontrolado.com/Mt/#Gravura"/> <raraa:patina rdf:resource="https://linkvocabcontrolado.com/Mt/#Ausente"/> <dbp:group rdf:resource="https://linkvocabcontrolado.com/Mt/#Figurativo"/> <dct:type rdf:resource="https://linkvocabcontrolado.com/Mt/#Armas"/> <raraa:subtype rdf:resource="https://linkvocabcontrolado.com/Mt/#Espada"/> <cidoc:P65_shows_visual_item>Não</cidoc:P65_shows_visual_item> <cidoc:P46i_forms_part_of rdf:resource="Af2"/> <dct:identifier rdf:resource="https://doi.org/10.5281/zenodo.6963462"/> </rdf:Description> </rdf:RDF> Grafo RDF Figura 36: Grafo resultante da classe Motivo 72 5.1.4 Parte Representada Código RDF <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:dbo="http://dbpedia.org/ontology/" xmlns:schema="http://schema.org/" xmlns:dbp="http://dbpedia.org/property/" xmlns:dct="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cidoc="http://cidoc-crm.org/cidoc-crm/7.1.1/" xmlns:ao="http://ariadne-infrastructure.eu/ns/" xmlns:raraa="http://linkclassespropriedades.com/property#"> <rdf:Description rdf:ID="PR11"> <rdf:type rdf:resource="http://cidoc-crm.org/cidoccrm/7.1.1/E26_Physical_Feature"/> <raraa:representedPart rdf:resource="https://linkvocabcontrolado.com/PR/#Lâmina"/> <dbp:shape rdf:resource="https://linkvocabcontrolado.com/PR/#Curvada"/> <cidoc:P46i_forms_part_of rdf:resource="https://linkdomotivo.com/#7"/> <dct:identifier rdf:resource="PR11"/> </rdf:Description> </rdf:RDF> Grafo RDF Figura 37: Grafo resultante da classe Parte Representada 73 5.1.5 Cena Código RDF <?xml version="1.0"?> <rdf:RDF xmlns:dbo="http://dbpedia.org/ontology/" xmlns:schema="http://schema.org/" xmlns:dbp="http://dbpedia.org/property/" xmlns:dct="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cidoc="http://cidoc-crm.org/cidoc-crm/7.1.1/" xmlns:ao="http://ariadne-infrastructure.eu/ns/" xmlns:raraa="http://linkclassespropriedades.com/property#"> <rdf:Description rdf:about="https://doi.org/10.5281/zenodo.6963660"> <rdf:type rdf:resource="http://cidoc-crm.org/cidoccrm/7.1.1/E36_Visual_Item"/> <cidoc:P1_is_identified_by>VRM003_E</cidoc:P1_is_identified_by> <dbo:Name>Cena de combate</dbo:Name> <schema:description>Combate entre um cavaleiro e um guerreiro na parte central inferior do painel 2.</schema:description> <dct:identifier rdf:resource="https://doi.org/10.5281/zenodo.6963660"/> <cidoc:P46i_forms_part_of rdf:resource="Af2"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963551"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963594"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963576"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963614"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963628"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963535"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963486"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963506"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963462"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963358"/> <cidoc:P46_is_composed_of rdf:resource="https://doi.org/10.5281/zenodo.6963328"/> </rdf:Description> </rdf:RDF> 74 Grafo RDF Figura 38: Grafo resultante da classe Cena 81 hierarquia de conceitos. Este vocabulário controlado é constituído, no total, por 377 conceitos, tendo estes sido codificados em SKOS. Foi utilizada a propriedade narrower do SKOS de forma a identificar as relações hierárquicas dos conceitos, como já salientado anteriormente. Esta propriedade foi atribuída aos conceitos mais gerais de forma a identificar quais os conceitos mais específicos que estão relacionados. Não foi utilizada a propriedade broader nos conceitos mais específicos de forma a evitar redundância. Estas propriedades são mencionadas na Secção 3.1.2. O código necessário para a representação deste vocabulário controlado da patine, demonstrado na Figura 39, em SKOS, será apresentado em seguida. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" > <!--Arte Rupestre--> <skos:ConceptScheme rdf:about="linkarterupestre"> <skos:prefLabel xml:lang="pt">Arte Rupestre</skos:prefLabel> <skos:prefLabel xml:lang="en">Rock Art</skos:prefLabel> <skos:prefLabel xml:lang="es">Arte Rupestre</skos:prefLabel> <skos:hasTopConcept rdf:resource="linkmotivo"/> <skos:hasTopConcept rdf:resource="linkafloramento"/> <skos:hasTopConcept rdf:resource="linkmotivo_grupos"/> <skos:hasTopConcept rdf:resource="linkParteRepresentada"/> </skos:ConceptScheme> <!--Motivo--> <skos:Concept rdf:about="linkmotivo"> <skos:inScheme rdf:resource="linkarterupestre"/> <skos:prefLabel xml:lang="pt">Motivo</skos:prefLabel> <skos:prefLabel xml:lang="en">Motif</skos:prefLabel> <skos:prefLabel xml:lang="es">Motivo</skos:prefLabel> <skos:narrower rdf:resource="linkestadoconservacao"/> <skos:narrower rdf:resource="linkcronologia"/> <skos:narrower rdf:resource="linkestilo"/> <skos:narrower rdf:resource="linktecnica"/> <skos:narrower rdf:resource="linktecnicavar"/> <skos:narrower rdf:resource="linkpatine"/> <skos:narrower rdf:resource="linkpintura"/> <skos:topConceptOf rdf:resource="linkarterupestre"/> </skos:Concept> <!--Motivo - Patine--> <skos:Concept rdf:about="linkpatine"> <skos:prefLabel xml:lang="pt">Patine</skos:prefLabel> <skos:prefLabel xml:lang="en">Patina</skos:prefLabel> <skos:prefLabel xml:lang="es">Pátina</skos:prefLabel> <skos:narrower rdf:resource="MPT01"/> <skos:narrower rdf:resource="MPT02"/> <skos:narrower rdf:resource="MPT03"/> <skos:broader rdf:resource="linkmotivo"/> 82 </skos:Concept> <skos:Concept rdf:about="MPT01"> <skos:prefLabel xml:lang="pt">Ausente</skos:prefLabel> <skos:prefLabel xml:lang="en">Absent</skos:prefLabel> <skos:prefLabel xml:lang="es">Ausente</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MPT02"> <skos:prefLabel xml:lang="pt">Parcial</skos:prefLabel> <skos:prefLabel xml:lang="en">Partial</skos:prefLabel> <skos:prefLabel xml:lang="es">Parcial</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MPT03"> <skos:prefLabel xml:lang="pt">Presente</skos:prefLabel> <skos:prefLabel xml:lang="en">Present</skos:prefLabel> <skos:prefLabel xml:lang="es">Presente</skos:prefLabel> </skos:Concept> Numa pesquisa inicial não foram encontrados vocabulários controlados que pudessem ser utilizados neste projeto. Mais tarde, numa nova pesquisa, foi encontrado um vocabulário controlado relativo à Litologia 12 , que poderá ser utilizado num trabalho futuro. Havendo também uma oportunidade de pesquisa de outros vocabulários controlados, que sejam criados posteriormente, que poderão ser utilizados. 12 https://apps.usgs.gov/thesaurus/thesaurus.php?thcode=4 83 5.4 Criação dos templates Shape Expressions (ShEx) A Shape Expressions (ShEx) consiste numa linguagem que estabelece restrições e condições para grafos RDF, de forma a definir como esse grafo deve estar estruturado para estar em conformidade com o pretendido. (W3C Community Group Draft Report, 2022) Foram criados templates ShEx para este projeto de forma a facilitar a validação dos dados resultantes do desenvolvimento deste, e que estão presentes no triplestore criado. A validação será apresentada na Secção 7.1. Para a criação dos templates foi utilizado o DCTAP. Isto deve-se ao facto de haver necessidade de ter definidas as propriedades, os tipos de valor de cada uma, e a sua obrigatoriedade para a sua criação, e o DCTAP descreve todas essas informações necessárias. Um exemplo do código desenvolvido para a tabela cena será apresentado de seguida. PREFIX cidoc: <http://cidoc-crm.org/cidoc-crm/7.1.1/> PREFIX dbp: <https://dbpedia.org/property/> PREFIX dbo: <https://dbpedia.org/ontology/> PREFIX schema: <https://schema.org/> PREFIX ao: <http://ariadne-infrastructure.eu/ns/> PREFIX dct: <http://purl.org/dc/terms/> PREFIX raraa: <http://linkclassespropriedades.com/property#> PREFIX raraaC: <http://linkclassespropriedades.com/class#> cidoc:E36_Visual_Item { cidoc:P1_is_identified_by LITERAL ? ; dbo:name LITERAL ? ; dct:description LITERAL ? ; dct:identifier IRI ; cidoc:P46i_forms_part_of IRI ; cidoc:P46_is_composed_of IRI ; } O restante código, relativo a todas as tabelas utilizadas neste projeto, pode ser encontrado no Apêndice B. De forma a verificar o código foi utilizada uma ferramenta online denominada RDFShape 13 . Esta ferramenta informa de possíveis erros no código, e caso este esteja correto é apresentado um modelo. Com esta ferramenta foram encontrados erros nas primeiras versões do código, que foram corrigidas mediante a informação dada. Como havia falta de domínio desta linguagem, foi necessária uma investigação inicial de documentação e de código disponibilizado online, que consequentemente deram origem a 13 https://rdfshape.weso.es/shexInfo 84 várias versões até chegar à final. Esta ferramenta utilizada foi bastante útil para perceber o que corrigir. Na Figura 40 está representado o modelo originado. Neste modelo podemos verificar as classes atribuídas a cada tabela e as respetivas propriedades de cada uma. Cada classe e o seu conjunto de propriedades constitui um shape. Figura 40: Modelo ShEx resultante 85 6. TRANSFORMAÇÃO, CARREGAMENTO E DISPONIBILIZAÇÃO DOS DADOS Foi necessário escolher um triplestore para o carregamento dos dados em RDF. Depois de bastante pesquisa e comparação entre as opções encontradas, estando estas demonstradas na Secção 3.1.4, optou-se por um com versão gratuita e com grande armazenamento. O triplestore escolhido foi o GraphDB. A escolha deste triplestore foi feita através da análise das duas melhores opções acordadas, o GraphDB e o OpenLink Virtuoso, tendo sido dado enfâse na quantidade de dados que era capaz de armazenar, e neste campo o GraphDB tinha-se mostrado mais vantajoso. Depois de instalado e de feita uma exploração das suas funcionalidades foi descoberto que existem três formas de inserir dados RDF no triplestore, sendo estas através do upload de ficheiros RDF, através de um URL com os dados em RDF, ou através da inserção direta de código RDF. Na Figura 41 está representado um diagrama com todo o processo de transformação, carregamento e disponibilização dos dados, demonstrando todas as ferramentas utilizadas. Figura 41: Diagrama do processo de Transformação e Carregamento dos dados Foi necessário passar os dados reais fornecidos em formato XML, provenientes da base de dados da UAUM, para a estrutura RDF anteriormente mencionada no Ponto 5.1. Para isso foi 86 utilizado o OpenRefine com a ajuda de uma extensão que suportasse a conversão de dados XML para RDF, com a estrutura definida, sendo esta a RDF-extension 14 . O OpenRefine é um software open source utilizado para limpar dados e transformá-los para outros formatos. A sua utilização foi necessária para a conversão dos ficheiros XML, provenientes da base de dados, em ficheiros RDF com a estrutura definida anteriormente. Para isso foram importados os ficheiros XML com os dados de cada tabela, e, com base no Perfil de Aplicação desenvolvido, foi definido o esqueleto RDF para cada um. Este esqueleto RDF é o que define quais a propriedades e classes a utilizar, e quais colunas do ficheiro XML que lhes corresponde. A Figura 42 apresenta um dos ficheiros XML carregado no OpenRefine. Figura 42: Ficheiro XML proveniente da tabela Cena importado no OpenRefine Devido à existência de valores nulos, mas identificados como “NULL” em string, foi necessário criar uma regra de transformação, em todas as colunas, onde qualquer valor que equivalesse à string “NULL” seria convertido para um verdadeiro valor nulo. Desta forma, ao exportar os dados estes não são incluídos, visto não haver necessidade de os incluir no código RDF dada a consequente presença de triplos vazios, aumentando o tamanho do código. Esta regra pode ser observada na Figura 43. 14 https://github.com/sparkica/rdf-extension 87 Figura 43: Regra para a remoção dos valores "NULL" Tal como mencionado anteriormente, foi necessária a criação dos esqueletos RDF definidos para cada tabela, sendo que estes, ou parte deles, podem ser observados nas Figuras 44 e 45. Para a definição dos esqueletos RDF foram utilizadas as propriedades e classes definidas no Perfil de Aplicação e que estão presentes nos templates ShEx. Posteriormente, esses templates foram utilizados para validar se os dados RDF são válidos e estavam de acordo com o definido. Nestes esqueletos RDF é necessário definir a tabela de prefixos, tal como está apresentado na Tabela 2. Depois são escolhidas as propriedades, através do uso do prefixo da ontologia a que pertence, seguido da indicação da coluna da base de dados a que se refere. Assim é definido como cada valor deve ser identificado em RDF, de forma que os triplos formados façam sentido e estejam de acordo com o estipulado para o projeto, mencionando também qual o formato dos dados. Todos os conjuntos de dados provenientes de cada tabela tiveram o seu esqueleto RDF definido. A grande vantagem da definição do Perfil de Aplicação é que todo este processo se torna mais fácil e rápido, visto tudo o que é necessário definir aqui no Open Refine já está definido no Perfil de Aplicação. Serão agora apresentados alguns dos esqueletos definidos para o Sítio/Núcleo, Afloramento, Motivo, Parte Representada e Cena. Nas Figuras 44 e 45 são apresentados os esqueletos do 88 Motivo e Cena. As propriedades utilizadas estão apresentadas na Tabela 3. A escolha de apresentar apenas estes esqueletos deve-se ao facto de a Cena ter um identificador para o Motivo e por isso é interessante mostrar como os dois estão estruturados. Figura 44: Parte do Esqueleto RDF da tabela Motivo Figura 45: Esqueleto RDF da tabela Cena Através destes Esqueletos RDF foi possível exportar ficheiros RDF com a estrutura definida, podendo assim prosseguir para a inserção desses dados no triplestore GraphDB. O código resultante pode ser encontrado no Apêndice C. 89 Comparando estes ficheiros com os criados manualmente, que estão disponíveis na Secção 5.1, alguns dos objetos não possuíam todas as propriedades, isto deve-se à existência de dados nulos que não foram incluídos, tal como explicado anteriormente. Apesar disso, os ficheiros não apresentavam diferença na estrutura. A importação dos ficheiros RDF gerados deu origem a cinco conjuntos de dados, correspondentes a cada tipo de objetos existentes neste projeto, tal como se pode observar na Figura 46. Figura 46: Conjuntos de dados RDF no GraphDB Esta inserção no triplestore deu origem a uma lista de triplos. Esta lista de triplos está apresentada, de forma parcial, na Figura 47. Não é apresentado o grafo resultante visto este ser bastante extenso e não ser legível no documento, tomando-se a decisão de o ocultar. Figura 47: Parte do Grafo em tabela relativo a todos os dados importados para o GraphDB 90 7. VALIDAÇÃO DOS DADOS Neste capítulo serão demonstradas as duas abordagens utilizadas, de forma a validar os dados que foram inseridos no triplestore, tal como demonstrado no Capítulo 6. A validação através da utilização dos templates ShEx tem como objetivo a verificação da estrutura do código RDF, de forma a validar os tipos de dados de cada triplo e validar se as propriedades definidas no template para cada shape são utilizadas devidamente. Já a validação através de Queries SPARQL tem como objetivo a verificação da transformação e inserção dos dados no triplestore, isto é, esta validação verifica se os dados foram bem transformados, através de queries feitas tanto no triplestore como na base de dados relacional, de onde estes têm origem. Se os resultados coincidirem então significa que a transformação e inserção foi bem-sucedida e que não houve alteração indevida dos dados. 7.1 Templates ShEx Para a validação dos dados através dos Templates ShEx criados anteriormente, foi utilizada uma ferramenta online 15 . Esta ferramenta permite a utilização dos templates ShEx para a validação da estrutura do código RDF, ou seja, é uma forma de verificar se os triplos desenvolvidos têm tipos de dados válidos, e se todas as propriedades definidas foram utilizadas, tendo em conta se estas são ou não obrigatórias Para a validação é necessário o código ShEx desenvolvido, que pode ser encontrado no Apêndice B, e o código RDF, em formato Turtle (Terse RDF Triple Language). Na Figura 48 é possível verificar como a ferramenta é utilizada, sendo que o código ShEx encontra-se no lado esquerdo e o código RDF no lado direito. 15 https://shex.io/webapps/shex.js/doc/shex-simple.html 97 8. CONCLUSÃO Neste capítulo serão apresentadas as conclusões finais deste projeto, sendo dado um contexto sobre este projeto, os resultados relacionados com os objetivos definidos e as limitações e trabalho futuro. 8.1 Contexto Existem dados sobre a arte rupestre do Vale do Côa que estão em bases de dados fechadas, o que impossibilita a sua utilização por quem a elas não tenha acesso. Uma dessas bases de dados é a da Unidade de Arqueologia da Universidade do Minho. Com isto, torna-se necessária a sua abertura, para que posteriormente os dados possam ser utilizados por investigadores fora da Universidade, também para o enriquecimento dos mesmos ao serem relacionados com outros de outros LD da área, possibilitando um crescimento na investigação desta área tanto para a Unidade de Arqueologia da Universidade do Minho como para outros investigadores. Este projeto vem possibilitar essa abertura dos dados através da perspetiva Linked Open Data. É dada uma explicação dos fundamentos teóricos, necessários para a compreensão do que é Linked Open Data, e os conceitos importantes que lhe estão relacionados, e é documentado todo o processo efetuado para que o resultado estivesse de acordo com os objetivos estipulados. 8.2 Resultados e contributos O principal objetivo deste projeto é a modelação e transformação dos dados da base de dados da UAUM, de forma a torná-los semanticamente interoperáveis. Para que esse objetivo fosse alcançado, foi necessário cumprir objetivos intermédios importantes. Primeiramente, foi necessário fazer uma investigação e revisão de leitura relativo ao estado da arte sobre o trabalho relacionado e fundamentos teóricos importantes. Toda a informação relevante encontrada pode ser consultada no Capítulo 3. 98 Era importante fazer um estudo sobre o domínio de aplicação, dando um contexto do que é o Vale do Côa, qual a sua importância neste projeto, o problema ao qual este projeto será a solução, e informação sobre os dados que serão utilizados. Esta informação pode ser encontrada nos Capítulos 1 e 2. Foram selecionados os métodos de investigação e de desenvolvimento de um perfil de aplicação, sendo que o primeiro ajudou em todo o desenvolvimento do projeto, e o segundo foi um método fulcral para que o desenvolvimento da modelação e transformação dos dados estivesse bem organizado e estruturado. O estudo feito sobre esses métodos está presente no Capítulo 4. Posteriormente, foi definido como os dados seriam recolhidos, processados, publicados e visualizados. Os dados são extraídos da base de dados para ficheiros XML, seguidamente foi escolhida a ferramenta OpenRefine para organizar esses dados e os transformar para XML/RDF, utilizando o Perfil de Aplicação criado como guia para as propriedades e classes a utilizar e a formatação dos dados, e como importar os dados para um triplestore, neste caso o GraphDB. Neste documento é mencionado tudo o que foi desenvolvido, dando toda a explicação de como foi feito e quais as decisões tomadas. Esta explicação foi dada ao longo dos Capítulos 5 e 6. Para a validação do protótipo desenvolvido, foram utilizados Templates ShEx de forma a validar a estrutura e o tipo dos dados, tendo em conta a estrutura definida no Perfil de Aplicação, e foram feitas queries SPARQL, de forma a perceber se os dados no triplestore estavam de acordo com o que estava presente na base de dados da UAUM, isto é, de forma a verificar se durante a transformação e inserção dos dados no triplestore nenhum dado foi indevidamente modificado ou excluído. No Capítulo 7 estão descritos o processo realizado e os resultados. Foi conseguido validar com sucesso o trabalho realizado. 8.2.1 Resultados • Modelação e transformação dos dados da base de dados da UAUM; • Perfil de aplicação; • Templates ShEx; • Esquema de classes e propriedades; • Vocabulários controlados codificados. 99 8.3 Limitações e Trabalho Futuro Como trabalho futuro, será necessário criar links e DOIs (Digital Object Identifier) para as classes, propriedades e vocabulário controlado codificado em SKOS, e para cada Sítio/Núcleo, Afloramento, Motivo, Parte Representada e Cena restantes, de forma a identificá-los individualmente. Neste momento apenas alguns dos Motivos e uma Cena foram identificados através de um DOI, os restantes foram identificados através de IDs internos ou links de exemplo para o seu armazenamento no triplestore. Também será necessário realizar a automatização da extração dos dados da base de dados, e inserção no triplestore. Neste momento a extração e inserção ainda são feitas manualmente, o que torna o processo mais trabalhoso, sendo mais vantajoso que este fosse feito de forma automática. Por fim, os dados não foram publicados na Web, mas estão disponíveis para serem inseridos num triplestore e potencialmente publicados para o público. Isto deve-se ao facto de ter sido dada a prioridade para os restantes passos, que necessitavam de mais atenção para que os dados ficassem corretamente modelados e estruturados. O que significa que, como trabalho futuro, será necessário publicar estes dados na Web para poderem ser utilizados por outros investigadores. 8.3.1 Contributos • Para outros investigadores: o Possibilidade de reutilização dos dados sobre a arte rupestre do Vale do Côa. • Para a UAUM: o Perfil de aplicação; o Vocabulários controlados codificados em SKOS; o Classes e propriedades criadas utilizado RDF Schema; o Armazenamento dos dados num triplestore; o Templates ShEx; o Possibilidade de abrir os dados para um maior público. 100 BIBLIOGRAFIA Almeida, B., & Costa, R. (2022). Guia para o desenvolvimento e publicação de vocabulários controlados. http://doi.org/10.34619/VW00-1KFH ARIADNE. (2012a). Activities – ARIADNE Infrastructure. Retrieved December 20, 2021, from http://legacy.ariadne-infrastructure.eu/about-ariadne/activities/ ARIADNE. (2012b). Ariadne Reference Model – ARIADNE Infrastructure. Retrieved December 20, 2021, from http://legacy.ariadne-infrastructure.eu/resources-2/ariadnereference-model/ ARIADNE. (2012c). Introduction – ARIADNE Infrastructure. Retrieved December 20, 2021, from http://legacy.ariadne-infrastructure.eu/about-ariadne/introduction/ ARIADNEplus. (2020a). About ARIADNEplus. ARIADNE PLUS. Retrieved December 20, 2021, from https://ariadne-infrastructure.eu/about-ariadne/ ARIADNEplus. (2020b). CIDADÃOS – ARIADNEplus PT. Retrieved February 9, 2022, from https://whatis.ariadne-infrastructure.eu/pt/cidadaos/ ARIADNEplus. (2020c). INVESTIGADORES – ARIADNEplus PT. Retrieved February 9, 2022, from https://whatis.ariadne-infrastructure.eu/pt/investigadores/ Aspöck, E. (2019). Moving towards an open archaeology: Projects, opportunities and challenges. VOEB-Mitteilungen, 72(2), 538–554. Scopus. http://doi.org/10.31263/voebm.v72i2.3249 Bardi, A., Binding, C., Felicetti, A., Kritsotakis, V., Meghini, C., Richards, J., & Theodoridou, M. (2022). ARIADNEplus Data Aggregation Pipeline: An Abbreviated Guide for Data Providers. 101 Bekiari, C., Bruseker, G., Doerr, M., Ore, C.-E., Stead, S., & Velios, A. (2021). Volume A: Definition of the CIDOC Conceptual Reference Model. 235. Berners-Lee, T. (2009, June 18). Linked Data. Linked Data - Design Issues. Retrieved November 2, 2021, from https://www.w3.org/DesignIssues/LinkedData.html Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic web. Scientific American, 284(5), 34–43. Botica, N., & Figueiredo, S. (2020, June 20). Repositório de Arte Rupestre de Acesso Aberto. Botica, N., Luís, L., & Silva, J.-P. (2022). Atributos e descritores propostos para a arte rupestre da Idade do Ferro no Vale do Côa. Cuadernos de Arqueología de la Universidad de Navarra. http://doi.org/10.15581/012.30.009 Brocke, J. vom, Hevner, A., & Maedche, A. (2020). Introduction to Design Science Research (pp. 1–13). http://doi.org/10.1007/978-3-030-46781-4_1 CoaParque. (2022). Parque. Côa Parque. Retrieved January 13, 2022, from https://artecoa.pt/parque/ Coyle, K. (2009, May 18). Guidelines for Dublin Core Application Profiles. Retrieved May 2, 2022, from https://www.dublincore.org/specifications/dublin-core/profileguidelines/ Coyle, K. (2020, December 7). DC Tabular Application Profiles. Retrieved August 13, 2022, from https://www.dublincore.org/blog/2020/dc_tabular_application_profiles/ DBpedia Association. (2021, March 5). About DBpedia. DBpedia Association. Retrieved August 6, 2022, from https://www.dbpedia.org/about/ DBpedia Association. (2021, July 23). Ontology (DBO). DBpedia Association. Retrieved January 9, 2023, from https://www.dbpedia.org/resources/ontology/ 102 DCMI. (2018, December 15). Application Profile. Retrieved June 17, 2022, from https://www.dublincore.org/resources/glossary/application_profile/ Doerr, M. (2005). The CIDOC CRM, an ontological approach to schema heterogeneity. Dagstuhl Seminar Proceedings. Doerr, M., Gradmann, S., Hennicke, S., Isaac, A., Meghini, C., & Van de Sompel, H. (2010). The europeana data model (edm). World Library and Information Congress: 76th IFLA General Conference and Assembly, 10, 15. Dublin Core Collection Description Task Group. (2007, March 9). Dublin Core Collection Description Application Profile. Retrieved May 2, 2022, from https://www.dublincore.org/specifications/dublin-core/collectiondescription/collection-application-profile/ Europeana. (2014, November 18). The Europeana Data Model for Cultural Heritage. Retrieved November 24, 2021, from https://pro.europeana.eu/files/Europeana_Professional/Share_your_data/Technical _requirements/EDM_Documentation/EDM_Factsheet.pdf Europeana. (2017, October 6). Definition of the Europeana Data Model v5.2.8. Retrieved November 24, 2021, from https://pro.europeana.eu/files/Europeana_Professional/Share_your_data/Technical _requirements/EDM_Documentation/EDM_Definition_v5.2.8_102017.pdf Finto. (2021, September 28). Finto: MAO/TAO - Ontology for Museum Domain and Applied Arts. Retrieved December 19, 2021, from https://finto.fi/maotao/en/ FORTH. (2015). CRMgeo: Linking the CIDOC CRM to GeoSPARQL through a Spatiotemporal Refinement. 103 FORTH. (2016). Definition of the CRMdig—An Extension of CIDOC-CRM to support provenance metadata. FORTH. (2022). CRMsci: The Scientific Observation Model—An Extension of CIDOC-CRM to support scientific observation. Gutierrez, C., Hurtado, C., & Vaisman, A. (2007). Introducing time into RDF. Knowledge and Data Engineering, IEEE Transactions On, 19, 207–218. http://doi.org/10.1109/TKDE.2007.34 Hassanzadeh, P., Hyvönen, E., Ikkala, E., Tuominen, J., Thomas, S., Wessman, A., & Rohiola, V. (2020). FindSampo platform for reporting and studying archaeological finds using citizen science. 2695, 33–40. Scopus. Retrieved from https://www.scopus.com/inward/record.uri?eid=2-s2.085095973132&partnerID=40&md5=b045bb281acda900c2610b27910c816c Hausenblas, M. (2012). 5-star Open Data. Retrieved November 2, 2021, from http://5stardata.info/en/ Heath, T. (2009, March 2). Linked Data? Web of Data? Semantic Web? WTF? at Tom Heath’s Displacement Activities. Linked Data? Web of Data? Semantic Web? WTF? At Tom Heath’s Displacement Activities. Retrieved November 2, 2021, from http://tomheath.com/blog/2009/03/linked-data-web-of-data-semantic-web-wtf/ Hevner, A. R. (2007). A Three Cycle View of Design Science Research. 19, 7. Idehen, K. U. (2017, July 24). Semantic Web Layer Cake Tweak, Explained. OpenLink Software Blog. Retrieved February 9, 2022, from https://medium.com/openlink-softwareblog/semantic-web-layer-cake-tweak-explained-6ba5c6ac3fab 104 Idehen, K. U. (2019, October 24). What is a SPARQL Endpoint, and why is it important? OpenLink Virtuoso Weblog. Retrieved February 3, 2022, from https://medium.com/virtuoso-blog/what-is-a-sparql-endpoint-and-why-is-itimportant-b3c9e6a20a8b Jorge, N., Medeiros, F., Alves, J. R., & Medina, S. (2017). Os Vocabulários Controlados na Organização e Gestão de Informação sobre Património Cultural: Orientações Práticas.[sl]: Grupo de Trabalho Sistemas de Informação em Museus (GT-SIM) da Associação Portuguesa de Bibliotecários, Arquivistas e Documentalistas (BAD). Kifer, M., & Boley, H. (2013, February). RIF Overview (Second Edition). Retrieved February 9, 2022, from https://www.w3.org/TR/rif-overview/ Koivunen, M.-R., & Miller, E. (2001, November 2). W3C Semantic Web Activity. Retrieved February 3, 2022, from https://www.w3.org/2001/12/semweb-fin/w3csw LeFebvre, M. J., Brenskelle, L., Wieczorek, J., Kansa, S. W., Kansa, E. C., Wallis, N. J., King, J. N., Emery, K. F., & Guralnick, R. (2019). ZooarchNet: Connecting zooarchaeological specimens to the biodiversity and archaeology data networks. PLoS ONE, 14(4). Scopus. http://doi.org/10.1371/journal.pone.0215369 Malta, M. C. (2017a). Me4MAP: Método para o desenvolvimento de perfis de aplicação de metadados (Webinar). 86. Malta, M. C. (2017b, May 31). Me4MAP: Um método para o desenvolvimento de perfis de aplicação de metadados. Retrieved June 20, 2022, from https://www.dublincore.org/webinars/2017/me4map_um_m%C3%A9todo_para_o_ desenvolvimento_de_perfis_de_aplica%C3%A7%C3%A3o_de_metadados/ 105 Malta, M. C., Baptista, A. A., Bermúdez-Sabel, H., & González-Blanco, E. (2018). Validation of a metadata application profile domain model. 11. MarkLogic. (2022). Data Hub. MarkLogic. Retrieved August 5, 2022, from https://www.marklogic.com/product/data-hub/ Matter, P., & Haslhofer, B. (2007). Putting the CIDOC CRM into Practice-Experiences and Challenges. OKF. (2015). The Open Definition—Open Definition—Defining Open in Open Data, Open Content and Open Knowledge. Retrieved November 11, 2021, from https://opendefinition.org/ Ontotext. (2021). What is an RDF Triplestore? Ontotext. Retrieved January 15, 2022, from https://www.ontotext.com/knowledgehub/fundamentals/what-is-rdf-triplestore/ Ontotext. (2022, August 3). About GraphDB — GraphDB 10.0.0 documentation. Retrieved August 6, 2022, from https://graphdb.ontotext.com/documentation/10.0/aboutgraphdb.html# Ontotext GraphDB. (2022). In Wikipedia. Retrieved from https://en.wikipedia.org/w/index.php?title=Ontotext_GraphDB&oldid=1097408232 OpenLink Software. (2019). OpenLink Software: Virtuoso Homepage. Retrieved August 6, 2022, from https://virtuoso.openlinksw.com/ Paveprime Ltd. (2019). CRMinf: The Argumentation Model—An Extension of CIDOC-CRM to support argumentation. PIN S.c.r.l. (2016). Definition of the CRMba—An extension of CIDOC CRM to support buildings archaeology documentation. 106 PIN, University of Florence. (2020). Definition of the CRMarchaeo—An Extension of CIDOC CRM to support the archaeological excavation process. RDF Working Group. (2014). RDF - Semantic Web Standards. Retrieved December 22, 2021, from https://www.w3.org/RDF/ Semantic Web Deployment Working Group. (2009). SKOS - Semantic Web Standards. Retrieved December 23, 2021, from https://www.w3.org/2001/sw/wiki/SKOS SIG, C. C. (2014). What is the CIDOC CRM? Retrieved November 24, 2021, from https://cidoccrm.org/ Silva, M., Martins, D., & Siqueira, J. (2019). Web semântica em repositórios: Ontologia para representação de bibliotecas digitais. Ciência Da Informação Em Revista, 6, 99. http://doi.org/10.28998/cirev.2019v6n1f SPARQL Working Group. (2013). SPARQL - Semantic Web Standards. Retrieved December 23, 2021, from https://www.w3.org/2001/sw/wiki/SPARQL Stardog Union. (2022). The Enterprise Knowledge Graph Platform—Product Page | Stardog. Stardog Union. Retrieved August 7, 2022, from https://www.stardog.com/platform/ TDWG. (2021, July 15). Darwin Core quick reference guide. Retrieved from https://dwc.tdwg.org/terms/ The Finnish Terminology Centre. (2016, June 14). Extended version of the MAO/TAO Ontology published in Finto | The Finnish Terminology Centre. Retrieved January 29, 2022, from http://www.tsk.fi/tsk/en/extended_version_of_the_maotao_ontology_published_in _finto-980.html The Finnish Terminology Centre. (2020, February 25). Updated MAO/TAO Ontology published in Finto service | The Finnish Terminology Centre. Retrieved January 29, 2022, from 113 Grupo Tipo Subtipo Outro Parte Representada Antropomorfos Boca Linear Modelada Naturalista Cabeça Alongada Bico de pássaro Circular Irregular Losangular Ovalada Triangular Mãos Mão direita Mão esquerda Com dedos Sem dedos Membros inferiores Membros superiores Lineares Linhas paralelas Linhas paralelas abertas Linhas paralelas fechadas Fletidos Nariz Retangular Triangular Olho Amendoada Circular Outra Ponto Orelha Definida ao longo do contorno Linear Retangular Orgãos sexuais Falo Vulva Pés Pé direito Pé esquerdo Com dedos Sem dedos Vestuário Botas Calçado Cinto Couraça Elmo Grebas Túnica Zoomorfos Barbada Bordo cervical Bordo ventral Crineira Crineira – bordo Crineira – exterior Queixo Concava Convexa Reta Boca Linear Modelada 114 Grupo Tipo Subtipo Naturalista Cabeça Alongada Angular Circular Contra topo orelha Irregular Losangular Ovalada Ponta destacada Triangular Chanfro Reto Cornos Contornados Lineares Corpo Curvas acentuadas Curvas suaves Linhas paralelas Linhas paralelas abertas Linhas paralelas fechadas Extremidade cranial Alteada Angular Contra topo orelha Ponta destacada Focinho Concavo Convexo Em aberto Modelado Reto Ganacha Convexa Membros anteriores Membros posteriores Fletidos Lineares Linhas paralelas Linhas paralelas abertas Linhas paralelas fechadas Triangulares Nuca Convexa Destacada Reta Triangular Olho Circular Ponto Orelha Definida ao longo do contorno Linear Retangular Pescoço Convexo Reto Armas Cabo Curto Curvo Longo Escudo Caetra Circular 115 Grupo Tipo Subtipo Oval Retangular Lâmina Curta Curvada Curvada estilo “Falcata” Longa Pomo Laminar Oval Redondo Retangular Triângular Tipologia Barcelos Bujões Curta Folha de Loureiro Retangular Semi-circular Skogstorp Triangular 116 APÊNDICES Apêndice A. Vocabulários Controlados codificados em SKOS <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" > <!--Arte Rupestre--> <skos:ConceptScheme rdf:about="linkarterupestre"> <skos:prefLabel xml:lang="pt">Arte Rupestre</skos:prefLabel> <skos:prefLabel xml:lang="en">Rock Art</skos:prefLabel> <skos:prefLabel xml:lang="es">Arte Rupestre</skos:prefLabel> <skos:hasTopConcept rdf:resource="linkmotivo"/> <skos:hasTopConcept rdf:resource="linkafloramento"/> <skos:hasTopConcept rdf:resource="linkmotivo_grupos"/> <skos:hasTopConcept rdf:resource="linkParteRepresentada"/> </skos:ConceptScheme> <!--Afloramento--> <skos:Concept rdf:about="linkafloramento"> <skos:inScheme rdf:resource="linkarterupestre"/> <skos:prefLabel xml:lang="pt">Afloramento</skos:prefLabel> <skos:prefLabel xml:lang="en">Outcrop</skos:prefLabel> <skos:prefLabel xml:lang="es">Afloramiento</skos:prefLabel> <skos:narrower rdf:resource="linksuportegeo"/> <skos:narrower rdf:resource="linklitologia"/> <skos:narrower rdf:resource="linklitologiaform"/> <skos:narrower rdf:resource="linkmorfologiasup"/> <skos:narrower rdf:resource="linkaspetosuperficie"/> <skos:narrower rdf:resource="linkconservacao"/> <skos:topConceptOf rdf:resource="linkarterupestre"/> </skos:Concept> <!--Afloramento - Suporte Geológico--> <skos:Concept rdf:about="linksuportegeo"> <skos:prefLabel xml:lang="pt">Suporte geológico</skos:prefLabel> <skos:prefLabel xml:lang="en">Geological support</skos:prefLabel> <skos:prefLabel xml:lang="es">Soporte geológico</skos:prefLabel> <skos:narrower rdf:resource="AFSG01"/> <skos:narrower rdf:resource="AFSG02"/> <skos:narrower rdf:resource="AFSG03"/> <skos:narrower rdf:resource="AFSG04"/> </skos:Concept> <skos:Concept rdf:about="AFSG01"> <skos:prefLabel xml:lang="pt">Diáclase</skos:prefLabel> <skos:prefLabel xml:lang="en">Diaclase</skos:prefLabel> <skos:prefLabel xml:lang="es">Diaclasa</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFSG02"> <skos:prefLabel xml:lang="pt">Falha</skos:prefLabel> <skos:prefLabel xml:lang="en">Fault</skos:prefLabel> 117 <skos:prefLabel xml:lang="es">Falla</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFSG03"> <skos:prefLabel xml:lang="pt">Xistosidade</skos:prefLabel> <skos:prefLabel xml:lang="en">Schistosity</skos:prefLabel> <skos:prefLabel xml:lang="es">Esquistosidad</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFSG04"> <skos:prefLabel xml:lang="pt">Outra</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otra</skos:prefLabel> </skos:Concept> <!--Afloramento - Litologia--> <skos:Concept rdf:about="linklitologia"> <skos:prefLabel xml:lang="pt">Litologia</skos:prefLabel> <skos:prefLabel xml:lang="en">Lithology</skos:prefLabel> <skos:prefLabel xml:lang="es">Litología</skos:prefLabel> <skos:narrower rdf:resource="AFLT01"/> <skos:narrower rdf:resource="AFLT02"/> <skos:narrower rdf:resource="AFLT03"/> <skos:narrower rdf:resource="AFLT04"/> <skos:narrower rdf:resource="AFLT05"/> <skos:narrower rdf:resource="AFLT06"/> <skos:narrower rdf:resource="AFLT07"/> </skos:Concept> <skos:Concept rdf:about="AFLT01"> <skos:prefLabel xml:lang="pt">Arenito</skos:prefLabel> <skos:prefLabel xml:lang="en">Sandstone</skos:prefLabel> <skos:prefLabel xml:lang="es">Arenisca</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLT02"> <skos:prefLabel xml:lang="pt">Calcário</skos:prefLabel> <skos:prefLabel xml:lang="en">Limestone</skos:prefLabel> <skos:prefLabel xml:lang="es">Caliza</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLT03"> <skos:prefLabel xml:lang="pt">Granito</skos:prefLabel> <skos:prefLabel xml:lang="en">Granite</skos:prefLabel> <skos:prefLabel xml:lang="es">Granito</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLT04"> <skos:prefLabel xml:lang="pt">Grauvaque</skos:prefLabel> <skos:prefLabel xml:lang="en">Greywacke</skos:prefLabel> <skos:prefLabel xml:lang="es">Grauvaca</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLT05"> <skos:prefLabel xml:lang="pt">Riólito</skos:prefLabel> <skos:prefLabel xml:lang="en">Rhyolite</skos:prefLabel> <skos:prefLabel xml:lang="es">Riolita</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLT06"> <skos:prefLabel xml:lang="pt">Xisto</skos:prefLabel> <skos:prefLabel xml:lang="en">Schist</skos:prefLabel> <skos:prefLabel xml:lang="es">Esquisto</skos:prefLabel> </skos:Concept> 118 <skos:Concept rdf:about="AFLT07"> <skos:prefLabel xml:lang="pt">Outro</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otro</skos:prefLabel> </skos:Concept> <!--Afloramento - Formação Litológica--> <skos:Concept rdf:about="linklitologiaform"> <skos:prefLabel xml:lang="pt">Formação Litológica</skos:prefLabel> <skos:prefLabel xml:lang="en">Lithological Formation</skos:prefLabel> <skos:prefLabel xml:lang="es">Formación Litológica</skos:prefLabel> <skos:narrower rdf:resource="AFLF01"/> <skos:narrower rdf:resource="AFLF02"/> <skos:narrower rdf:resource="AFLF03"/> </skos:Concept> <skos:Concept rdf:about="AFLF01"> <skos:prefLabel xml:lang="pt">Desejosa</skos:prefLabel> <skos:prefLabel xml:lang="en">Desejosa</skos:prefLabel> <skos:prefLabel xml:lang="es">Desejosa</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLF02"> <skos:prefLabel xml:lang="pt">Pinhão</skos:prefLabel> <skos:prefLabel xml:lang="en">Pinhão</skos:prefLabel> <skos:prefLabel xml:lang="es">Pinhão</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFLF03"> <skos:prefLabel xml:lang="pt">Rio Pinhão</skos:prefLabel> <skos:prefLabel xml:lang="en">Pinhão River</skos:prefLabel> <skos:prefLabel xml:lang="es">Río Pinhão</skos:prefLabel> </skos:Concept> <!--Afloramento - Morfologia superfície--> <skos:Concept rdf:about="linkmorfologiasup"> <skos:prefLabel xml:lang="pt">Morfologia superfície</skos:prefLabel> <skos:prefLabel xml:lang="en">Surface Morphology</skos:prefLabel> <skos:prefLabel xml:lang="es">Morfología de la superficie</skos:prefLabel> <skos:narrower rdf:resource="AFMS01"/> <skos:narrower rdf:resource="AFMS02"/> <skos:narrower rdf:resource="AFMS03"/> <skos:narrower rdf:resource="AFMS04"/> </skos:Concept> <skos:Concept rdf:about="AFMS01"> <skos:prefLabel xml:lang="pt">Côncava</skos:prefLabel> <skos:prefLabel xml:lang="en">Concave</skos:prefLabel> <skos:prefLabel xml:lang="es">Cóncava</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFMS02"> <skos:prefLabel xml:lang="pt">Convexa</skos:prefLabel> <skos:prefLabel xml:lang="en">Convex</skos:prefLabel> <skos:prefLabel xml:lang="es">Convexa</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFMS03"> <skos:prefLabel xml:lang="pt">Plana</skos:prefLabel> <skos:prefLabel xml:lang="en">Flat</skos:prefLabel> <skos:prefLabel xml:lang="es">Plana</skos:prefLabel> 119 </skos:Concept> <skos:Concept rdf:about="AFMS04"> <skos:prefLabel xml:lang="pt">Outra</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otra</skos:prefLabel> </skos:Concept> <!--Afloramento Aspeto Superfície--> <skos:Concept rdf:about="linkaspetosuperficie"> <skos:prefLabel xml:lang="pt">Aspeto Superfície</skos:prefLabel> <skos:prefLabel xml:lang="en">Surface Appearance</skos:prefLabel> <skos:prefLabel xml:lang="es">Aspecto de la superficie</skos:prefLabel> <skos:narrower rdf:resource="AFAS01"/> <skos:narrower rdf:resource="AFAS02"/> <skos:narrower rdf:resource="AFAS03"/> <skos:narrower rdf:resource="AFAS04"/> <skos:narrower rdf:resource="AFAS05"/> <skos:narrower rdf:resource="AFAS06"/> <skos:narrower rdf:resource="AFAS07"/> <skos:narrower rdf:resource="AFAS08"/> <skos:narrower rdf:resource="AFAS09"/> <skos:narrower rdf:resource="AFAS10"/> </skos:Concept> <skos:Concept rdf:about="AFAS01"> <skos:prefLabel xml:lang="pt">Acidentada</skos:prefLabel> <skos:prefLabel xml:lang="en">Hilly</skos:prefLabel> <skos:prefLabel xml:lang="es">Accidentada</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS02"> <skos:prefLabel xml:lang="pt">Bruto</skos:prefLabel> <skos:prefLabel xml:lang="en">Rough</skos:prefLabel> <skos:prefLabel xml:lang="es">Áspero</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS03"> <skos:prefLabel xml:lang="pt">Fraturas/Fissuras</skos:prefLabel> <skos:prefLabel xml:lang="en">Fractures/Cracks</skos:prefLabel> <skos:prefLabel xml:lang="es">Fracturas/Grietas</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS04"> <skos:prefLabel xml:lang="pt">Lisa</skos:prefLabel> <skos:prefLabel xml:lang="en">Flat</skos:prefLabel> <skos:prefLabel xml:lang="es">Lisa</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS05"> <skos:prefLabel xml:lang="pt">Nódulos/Veios</skos:prefLabel> <skos:prefLabel xml:lang="en">Nodules/Seams</skos:prefLabel> <skos:prefLabel xml:lang="es">Nódulos/Venas</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS06"> <skos:prefLabel xml:lang="pt">Polimento artificial</skos:prefLabel> <skos:prefLabel xml:lang="en">Artificial polishing</skos:prefLabel> <skos:prefLabel xml:lang="es">Pulido artificial</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS07"> <skos:prefLabel xml:lang="pt">Polimento natural</skos:prefLabel> <skos:prefLabel xml:lang="en">Natural polishing</skos:prefLabel> 120 <skos:prefLabel xml:lang="es">Pulido natural</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS08"> <skos:prefLabel xml:lang="pt">Rugosa</skos:prefLabel> <skos:prefLabel xml:lang="en">Rugged</skos:prefLabel> <skos:prefLabel xml:lang="es">Rugosa</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS09"> <skos:prefLabel xml:lang="pt">Talhada</skos:prefLabel> <skos:prefLabel xml:lang="en">Carved</skos:prefLabel> <skos:prefLabel xml:lang="es">Tallada</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFAS10"> <skos:prefLabel xml:lang="pt">Outra</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otra</skos:prefLabel> </skos:Concept> <!--Afloramento - Conservação--> <skos:Concept rdf:about="linkconservacao"> <skos:prefLabel xml:lang="pt">Conservação</skos:prefLabel> <skos:prefLabel xml:lang="en">Conservation</skos:prefLabel> <skos:prefLabel xml:lang="es">Conservación</skos:prefLabel> <skos:narrower rdf:resource="AFCS01"/> <skos:narrower rdf:resource="AFCS02"/> <skos:narrower rdf:resource="AFCS03"/> </skos:Concept> <skos:Concept rdf:about="AFCS01"> <skos:prefLabel xml:lang="pt">Completa</skos:prefLabel> <skos:prefLabel xml:lang="en">Complete</skos:prefLabel> <skos:prefLabel xml:lang="es">Completa</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFCS02"> <skos:prefLabel xml:lang="pt">Fraturada</skos:prefLabel> <skos:prefLabel xml:lang="en">Fractured</skos:prefLabel> <skos:prefLabel xml:lang="es">Fracturada</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="AFCS03"> <skos:prefLabel xml:lang="pt">Outra</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otra</skos:prefLabel> </skos:Concept> <!--Motivo--> <skos:Concept rdf:about="linkmotivo"> <skos:inScheme rdf:resource="linkarterupestre"/> <skos:prefLabel xml:lang="pt">Motivo</skos:prefLabel> <skos:prefLabel xml:lang="en">Motif</skos:prefLabel> <skos:prefLabel xml:lang="es">Motivo</skos:prefLabel> <skos:narrower rdf:resource="linkestadoconservacao"/> <skos:narrower rdf:resource="linkcronologia"/> <skos:narrower rdf:resource="linkestilo"/> <skos:narrower rdf:resource="linktecnica"/> <skos:narrower rdf:resource="linktecnicavar"/> <skos:narrower rdf:resource="linkpatine"/> <skos:narrower rdf:resource="linkpintura"/> 121 <skos:topConceptOf rdf:resource="linkarterupestre"/> </skos:Concept> <!--Motivo - Estado de conservação--> <skos:Concept rdf:about="linkestadoconservacao"> <skos:prefLabel xml:lang="pt">Estado de conservação</skos:prefLabel> <skos:prefLabel xml:lang="en">Conservation status</skos:prefLabel> <skos:prefLabel xml:lang="es">Estado de conservación</skos:prefLabel> <skos:narrower rdf:resource="MEC01"/> <skos:narrower rdf:resource="MEC02"/> <skos:narrower rdf:resource="MEC03"/> <skos:narrower rdf:resource="MEC04"/> <skos:narrower rdf:resource="MEC05"/> <skos:narrower rdf:resource="MEC06"/> <skos:narrower rdf:resource="MEC07"/> <skos:narrower rdf:resource="MEC08"/> <skos:narrower rdf:resource="MEC09"/> </skos:Concept> <skos:Concept rdf:about="MEC01"> <skos:prefLabel xml:lang="pt">Bom</skos:prefLabel> <skos:prefLabel xml:lang="en">Good</skos:prefLabel> <skos:prefLabel xml:lang="es">Bueno</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC02"> <skos:prefLabel xml:lang="pt">Deficiente</skos:prefLabel> <skos:prefLabel xml:lang="en">Deficient</skos:prefLabel> <skos:prefLabel xml:lang="es">Discapacitado</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC03"> <skos:prefLabel xml:lang="pt">Desaparecido</skos:prefLabel> <skos:prefLabel xml:lang="en">Missing</skos:prefLabel> <skos:prefLabel xml:lang="es">Desaparecido</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC04"> <skos:prefLabel xml:lang="pt">Destruído</skos:prefLabel> <skos:prefLabel xml:lang="en">Destroyed</skos:prefLabel> <skos:prefLabel xml:lang="es">Destruido</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC05"> <skos:prefLabel xml:lang="pt">Em perigo</skos:prefLabel> <skos:prefLabel xml:lang="en">In danger</skos:prefLabel> <skos:prefLabel xml:lang="es">En peligro</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC06"> <skos:prefLabel xml:lang="pt">Mau</skos:prefLabel> <skos:prefLabel xml:lang="en">Bad</skos:prefLabel> <skos:prefLabel xml:lang="es">Malo</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC07"> <skos:prefLabel xml:lang="pt">Muito Bom</skos:prefLabel> <skos:prefLabel xml:lang="en">Very Good</skos:prefLabel> <skos:prefLabel xml:lang="es">Muy Bueno</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC08"> <skos:prefLabel xml:lang="pt">Regular</skos:prefLabel> <skos:prefLabel xml:lang="en">Regular</skos:prefLabel> 122 <skos:prefLabel xml:lang="es">Regular</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MEC09"> <skos:prefLabel xml:lang="pt">Submerso</skos:prefLabel> <skos:prefLabel xml:lang="en">Submerged</skos:prefLabel> <skos:prefLabel xml:lang="es">Sumergido</skos:prefLabel> </skos:Concept> <!--Motivo - Cronologia--> <skos:Concept rdf:about="linkcronologia"> <skos:prefLabel xml:lang="pt">Cronologia</skos:prefLabel> <skos:prefLabel xml:lang="en">Chronology</skos:prefLabel> <skos:prefLabel xml:lang="es">Cronología</skos:prefLabel> <skos:narrower rdf:resource="MCR01"/> <skos:narrower rdf:resource="MCR02"/> <skos:narrower rdf:resource="MCR03"/> <skos:narrower rdf:resource="MCR04"/> <skos:narrower rdf:resource="MCR05"/> <skos:narrower rdf:resource="MCR06"/> <skos:narrower rdf:resource="MCR07"/> <skos:narrower rdf:resource="MCR08"/> <skos:narrower rdf:resource="MCR09"/> <skos:narrower rdf:resource="MCR10"/> <skos:narrower rdf:resource="MCR11"/> <skos:narrower rdf:resource="MCR12"/> <skos:narrower rdf:resource="MCR13"/> <skos:narrower rdf:resource="MCR14"/> <skos:narrower rdf:resource="MCR15"/> <skos:narrower rdf:resource="MCR16"/> <skos:narrower rdf:resource="MCR17"/> <skos:narrower rdf:resource="MCR18"/> <skos:narrower rdf:resource="MCR19"/> <skos:narrower rdf:resource="MCR20"/> <skos:narrower rdf:resource="MCR21"/> <skos:narrower rdf:resource="MCR22"/> <skos:narrower rdf:resource="MCR23"/> <skos:broader rdf:resource="linkmotivo"/> </skos:Concept> <skos:Concept rdf:about="MCR01"> <skos:prefLabel xml:lang="pt">Alta Idade Média</skos:prefLabel> <skos:prefLabel xml:lang="en">Early Middle Ages</skos:prefLabel> <skos:prefLabel xml:lang="es">Alta Edad Media</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MCR02"> <skos:prefLabel xml:lang="pt">Aurinhacense</skos:prefLabel> <skos:prefLabel xml:lang="en">Aurignacian</skos:prefLabel> <skos:prefLabel xml:lang="es">Aurinhacense</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MCR03"> <skos:prefLabel xml:lang="pt">Azilense</skos:prefLabel> <skos:prefLabel xml:lang="en">Azilian</skos:prefLabel> <skos:prefLabel xml:lang="es">Azilense</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MCR04"> <skos:prefLabel xml:lang="pt">Calcolítico</skos:prefLabel> <skos:prefLabel xml:lang="en">Chalcolithic</skos:prefLabel> 129 <skos:prefLabel xml:lang="en">Arabic numerals</skos:prefLabel> <skos:prefLabel xml:lang="es">Números arábigos</skos:prefLabel> <skos:narrower rdf:resource="MGAN01"/> <skos:narrower rdf:resource="MGAN02"/> </skos:Concept> <skos:Concept rdf:about="MGA05"> <skos:prefLabel xml:lang="pt">Numeração romana</skos:prefLabel> <skos:prefLabel xml:lang="en">Roman numerals</skos:prefLabel> <skos:prefLabel xml:lang="es">Números romanos</skos:prefLabel> <skos:narrower rdf:resource="MGAN01"/> <skos:narrower rdf:resource="MGAN02"/> </skos:Concept> <!-- Subtipos dos caracteres --> <skos:Concept rdf:about="MGAC01"> <skos:prefLabel xml:lang="pt">Frase</skos:prefLabel> <skos:prefLabel xml:lang="en">Sentence</skos:prefLabel> <skos:prefLabel xml:lang="es">Frase</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGAC02"> <skos:prefLabel xml:lang="pt">Impropério</skos:prefLabel> <skos:prefLabel xml:lang="en">Insult</skos:prefLabel> <skos:prefLabel xml:lang="es">Improperio</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGAC03"> <skos:prefLabel xml:lang="pt">Iniciais</skos:prefLabel> <skos:prefLabel xml:lang="en">Initials</skos:prefLabel> <skos:prefLabel xml:lang="es">Iniciales</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGAC04"> <skos:prefLabel xml:lang="pt">Localidade</skos:prefLabel> <skos:prefLabel xml:lang="en">Locality</skos:prefLabel> <skos:prefLabel xml:lang="es">Localidad</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGAC05"> <skos:prefLabel xml:lang="pt">Nome</skos:prefLabel> <skos:prefLabel xml:lang="en">Name</skos:prefLabel> <skos:prefLabel xml:lang="es">Nombre</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGAC06"> <skos:prefLabel xml:lang="pt">Outros</skos:prefLabel> <skos:prefLabel xml:lang="en">Others</skos:prefLabel> <skos:prefLabel xml:lang="es">Otros</skos:prefLabel> </skos:Concept> <!-- Subtipos da numeração --> <skos:Concept rdf:about="MGAN01"> <skos:prefLabel xml:lang="pt">Outros</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otros</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGAN02"> <skos:prefLabel xml:lang="pt">Datas</skos:prefLabel> <skos:prefLabel xml:lang="en">Dates</skos:prefLabel> <skos:prefLabel xml:lang="es">Fechas</skos:prefLabel> </skos:Concept> 130 <!--Motivo-Grupos - Figurativo--> <skos:Concept rdf:about="linkfigurativo"> <skos:prefLabel xml:lang="pt">Figurativo</skos:prefLabel> <skos:prefLabel xml:lang="en">Figurative</skos:prefLabel> <skos:prefLabel xml:lang="es">Figurativo</skos:prefLabel> <skos:narrower rdf:resource="MGF01"/> <skos:narrower rdf:resource="MGF02"/> <skos:narrower rdf:resource="MGF03"/> <skos:narrower rdf:resource="MGF04"/> <skos:narrower rdf:resource="MGF05"/> <skos:narrower rdf:resource="MGF06"/> <skos:narrower rdf:resource="MGF07"/> <skos:narrower rdf:resource="MGF08"/> <skos:narrower rdf:resource="MGF09"/> <skos:narrower rdf:resource="MGF10"/> <skos:broader rdf:resource="linkmotivo_grupos"/> </skos:Concept> <skos:Concept rdf:about="MGF01"> <skos:prefLabel xml:lang="pt">Antropomorfos</skos:prefLabel> <skos:prefLabel xml:lang="en">Anthropomorphs</skos:prefLabel> <skos:prefLabel xml:lang="es">Antropomorfos</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFA01"> <skos:prefLabel xml:lang="pt">Feminino</skos:prefLabel> <skos:prefLabel xml:lang="en">Female</skos:prefLabel> <skos:prefLabel xml:lang="es">Femenino</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFA02"> <skos:prefLabel xml:lang="pt">Indefinido</skos:prefLabel> <skos:prefLabel xml:lang="en">Undefined</skos:prefLabel> <skos:prefLabel xml:lang="es">Indefinido</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFA03"> <skos:prefLabel xml:lang="pt">Maniforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Maniform</skos:prefLabel> <skos:prefLabel xml:lang="es">Maniforme</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFA04"> <skos:prefLabel xml:lang="pt">Masculino</skos:prefLabel> <skos:prefLabel xml:lang="en">Male</skos:prefLabel> <skos:prefLabel xml:lang="es">Masculino</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFA05"> <skos:prefLabel xml:lang="pt">Podomorfo</skos:prefLabel> <skos:prefLabel xml:lang="en">Podomorph</skos:prefLabel> <skos:prefLabel xml:lang="es">Podomorfo</skos:prefLabel> </skos:Concept> 131 </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF02"> <skos:prefLabel xml:lang="pt">Zoomorfo</skos:prefLabel> <skos:prefLabel xml:lang="en">Zoomorph</skos:prefLabel> <skos:prefLabel xml:lang="es">Zoomorfo</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFZ01"> <skos:prefLabel xml:lang="pt">Animal irreal</skos:prefLabel> <skos:prefLabel xml:lang="en">Unreal Animal</skos:prefLabel> <skos:prefLabel xml:lang="es">Animal irreal</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ02"> <skos:prefLabel xml:lang="pt">Auroque</skos:prefLabel> <skos:prefLabel xml:lang="en">Aurochs</skos:prefLabel> <skos:prefLabel xml:lang="es">Aurochs</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ03"> <skos:prefLabel xml:lang="pt">Ave</skos:prefLabel> <skos:prefLabel xml:lang="en">Bird</skos:prefLabel> <skos:prefLabel xml:lang="es">Ave</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ04"> <skos:prefLabel xml:lang="pt">Bisonte</skos:prefLabel> <skos:prefLabel xml:lang="en">Bison</skos:prefLabel> <skos:prefLabel xml:lang="es">Bisonte</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ05"> <skos:prefLabel xml:lang="pt">Boi Almiscarado</skos:prefLabel> <skos:prefLabel xml:lang="en">Musk Ox</skos:prefLabel> <skos:prefLabel xml:lang="es">Buey almizclero</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ06"> <skos:prefLabel xml:lang="pt">Bovídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Bovine</skos:prefLabel> <skos:prefLabel xml:lang="es">Bovidae</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ07"> <skos:prefLabel xml:lang="pt">Canídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Canid</skos:prefLabel> <skos:prefLabel xml:lang="es">Cánido</skos:prefLabel> </skos:Concept> </skos:narrower> 132 <skos:narrower> <skos:Concept rdf:about="MGFZ08"> <skos:prefLabel xml:lang="pt">Capra ibex</skos:prefLabel> <skos:prefLabel xml:lang="en">Capra ibex</skos:prefLabel> <skos:prefLabel xml:lang="es">Capra ibex</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ09"> <skos:prefLabel xml:lang="pt">Capra pyrenaica</skos:prefLabel> <skos:prefLabel xml:lang="en">Capra pyrenaica</skos:prefLabel> <skos:prefLabel xml:lang="es">Capra pyrenaica</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ10"> <skos:prefLabel xml:lang="pt">Caprídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Caprine</skos:prefLabel> <skos:prefLabel xml:lang="es">Caprino</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ11"> <skos:prefLabel xml:lang="pt">Cervídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Cervid</skos:prefLabel> <skos:prefLabel xml:lang="es">Cérvido</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ12"> <skos:prefLabel xml:lang="pt">Corço</skos:prefLabel> <skos:prefLabel xml:lang="en">Buck</skos:prefLabel> <skos:prefLabel xml:lang="es">Corzo</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ13"> <skos:prefLabel xml:lang="pt">Equídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Equine</skos:prefLabel> <skos:prefLabel xml:lang="es">Equino</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ14"> <skos:prefLabel xml:lang="pt">Felídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Felid</skos:prefLabel> <skos:prefLabel xml:lang="es">Félido</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ15"> <skos:prefLabel xml:lang="pt">Javali</skos:prefLabel> <skos:prefLabel xml:lang="en">Boar</skos:prefLabel> <skos:prefLabel xml:lang="es">Jabalí</skos:prefLabel> </skos:Concept> 133 </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ16"> <skos:prefLabel xml:lang="pt">Mamute</skos:prefLabel> <skos:prefLabel xml:lang="en">Mammoth</skos:prefLabel> <skos:prefLabel xml:lang="es">Mamut</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ17"> <skos:prefLabel xml:lang="pt">Megaceros</skos:prefLabel> <skos:prefLabel xml:lang="en">Megaloceros</skos:prefLabel> <skos:prefLabel xml:lang="es">Megaceros</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ18"> <skos:prefLabel xml:lang="pt">Mustelídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Mustelid</skos:prefLabel> <skos:prefLabel xml:lang="es">Mustélido</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ19"> <skos:prefLabel xml:lang="pt">Outro</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otro</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ20"> <skos:prefLabel xml:lang="pt">Peixe</skos:prefLabel> <skos:prefLabel xml:lang="en">Fish</skos:prefLabel> <skos:prefLabel xml:lang="es">Pescado</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ21"> <skos:prefLabel xml:lang="pt">Quadrúpede</skos:prefLabel> <skos:prefLabel xml:lang="en">Quadruped</skos:prefLabel> <skos:prefLabel xml:lang="es">Cuadrúpedo</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ22"> <skos:prefLabel xml:lang="pt">Rena</skos:prefLabel> <skos:prefLabel xml:lang="en">Reindeer</skos:prefLabel> <skos:prefLabel xml:lang="es">Reno</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ23"> <skos:prefLabel xml:lang="pt">Rinoceronte</skos:prefLabel> <skos:prefLabel xml:lang="en">Rhinoceros</skos:prefLabel> <skos:prefLabel xml:lang="es">Rinoceronte</skos:prefLabel> 134 </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ24"> <skos:prefLabel xml:lang="pt">Serpente</skos:prefLabel> <skos:prefLabel xml:lang="en">Serpent</skos:prefLabel> <skos:prefLabel xml:lang="es">Serpiente</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ25"> <skos:prefLabel xml:lang="pt">Suíno</skos:prefLabel> <skos:prefLabel xml:lang="en">Swine</skos:prefLabel> <skos:prefLabel xml:lang="es">Cerdo</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ26"> <skos:prefLabel xml:lang="pt">Ursídeo</skos:prefLabel> <skos:prefLabel xml:lang="en">Ursid</skos:prefLabel> <skos:prefLabel xml:lang="es">Ursidium</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFZ27"> <skos:prefLabel xml:lang="pt">Veado</skos:prefLabel> <skos:prefLabel xml:lang="en">Deer</skos:prefLabel> <skos:prefLabel xml:lang="es">Ciervo</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF03"> <skos:prefLabel xml:lang="pt">Armas</skos:prefLabel> <skos:prefLabel xml:lang="en">Weapons</skos:prefLabel> <skos:prefLabel xml:lang="es">Armas</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFAr01"> <skos:prefLabel xml:lang="pt">Adaga</skos:prefLabel> <skos:prefLabel xml:lang="en">Dirk</skos:prefLabel> <skos:prefLabel xml:lang="es">Daga</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr02"> <skos:prefLabel xml:lang="pt">Alabarda</skos:prefLabel> <skos:prefLabel xml:lang="en">Halberd</skos:prefLabel> <skos:prefLabel xml:lang="es">Alabarda</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr03"> <skos:prefLabel xml:lang="pt">Arco</skos:prefLabel> <skos:prefLabel xml:lang="en">Bow</skos:prefLabel> <skos:prefLabel xml:lang="es">Arco</skos:prefLabel> </skos:Concept> 135 </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr04"> <skos:prefLabel xml:lang="pt">Escudo</skos:prefLabel> <skos:prefLabel xml:lang="en">Shield</skos:prefLabel> <skos:prefLabel xml:lang="es">Escudo</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr05"> <skos:prefLabel xml:lang="pt">Espada</skos:prefLabel> <skos:prefLabel xml:lang="en">Sword</skos:prefLabel> <skos:prefLabel xml:lang="es">Espada</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr06"> <skos:prefLabel xml:lang="pt">Falcata</skos:prefLabel> <skos:prefLabel xml:lang="en">Falcata</skos:prefLabel> <skos:prefLabel xml:lang="es">Falcata</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr07"> <skos:prefLabel xml:lang="pt">Flecha</skos:prefLabel> <skos:prefLabel xml:lang="en">Arrow</skos:prefLabel> <skos:prefLabel xml:lang="es">Flecha</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr08"> <skos:prefLabel xml:lang="pt">Javalina</skos:prefLabel> <skos:prefLabel xml:lang="en">Javalina</skos:prefLabel> <skos:prefLabel xml:lang="es">Javalina</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr09"> <skos:prefLabel xml:lang="pt">Lança</skos:prefLabel> <skos:prefLabel xml:lang="en">Spear</skos:prefLabel> <skos:prefLabel xml:lang="es">Lanza</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr10"> <skos:prefLabel xml:lang="pt">Machado</skos:prefLabel> <skos:prefLabel xml:lang="en">Axe</skos:prefLabel> <skos:prefLabel xml:lang="es">Hacha</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr11"> <skos:prefLabel xml:lang="pt">Outro</skos:prefLabel> <skos:prefLabel xml:lang="en">Other</skos:prefLabel> <skos:prefLabel xml:lang="es">Otro</skos:prefLabel> 136 </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr12"> <skos:prefLabel xml:lang="pt">Punhal</skos:prefLabel> <skos:prefLabel xml:lang="en">Dagger</skos:prefLabel> <skos:prefLabel xml:lang="es">Puñal</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr13"> <skos:prefLabel xml:lang="pt">Punho</skos:prefLabel> <skos:prefLabel xml:lang="en">Fist</skos:prefLabel> <skos:prefLabel xml:lang="es">Puño</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr14"> <skos:prefLabel xml:lang="pt">Seta</skos:prefLabel> <skos:prefLabel xml:lang="en">Arrow</skos:prefLabel> <skos:prefLabel xml:lang="es">Flecha</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFAr15"> <skos:prefLabel xml:lang="pt">Vara</skos:prefLabel> <skos:prefLabel xml:lang="en">Rod</skos:prefLabel> <skos:prefLabel xml:lang="es">Varilla</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF04"> <skos:prefLabel xml:lang="pt">Barquiforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Barquiform</skos:prefLabel> <skos:prefLabel xml:lang="es">Barquiforme</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGF05"> <skos:prefLabel xml:lang="pt">Labirinto</skos:prefLabel> <skos:prefLabel xml:lang="en">Maze</skos:prefLabel> <skos:prefLabel xml:lang="es">Laberinto</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="MGF06"> <skos:prefLabel xml:lang="pt">Escadiformes</skos:prefLabel> <skos:prefLabel xml:lang="en">Scadiformes</skos:prefLabel> <skos:prefLabel xml:lang="es">Escadiformes</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFE01"> <skos:prefLabel xml:lang="pt">Horizontal</skos:prefLabel> <skos:prefLabel xml:lang="en">Horizontal</skos:prefLabel> <skos:prefLabel xml:lang="es">Horizontal</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFE02"> <skos:prefLabel xml:lang="pt">Vertical</skos:prefLabel> 137 <skos:prefLabel xml:lang="en">Vertical</skos:prefLabel> <skos:prefLabel xml:lang="es">Vertical</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF07"> <skos:prefLabel xml:lang="pt">Esteliformes</skos:prefLabel> <skos:prefLabel xml:lang="en">Stelliformes</skos:prefLabel> <skos:prefLabel xml:lang="es">Esteliformes</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFEs01"> <skos:prefLabel xml:lang="pt">Asterisco</skos:prefLabel> <skos:prefLabel xml:lang="en">Asterisk</skos:prefLabel> <skos:prefLabel xml:lang="es">Asterisco</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFEs02"> <skos:prefLabel xml:lang="pt">Esteliforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Stelliform</skos:prefLabel> <skos:prefLabel xml:lang="es">Esteliforme</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFEs03"> <skos:prefLabel xml:lang="pt">Soliforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Soliform</skos:prefLabel> <skos:prefLabel xml:lang="es">Soliforme</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF08"> <skos:prefLabel xml:lang="pt">Ramiformes</skos:prefLabel> <skos:prefLabel xml:lang="en">Ramiforms</skos:prefLabel> <skos:prefLabel xml:lang="es">Ramiformes</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFR01"> <skos:prefLabel xml:lang="pt">Arboriforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Arboriform</skos:prefLabel> <skos:prefLabel xml:lang="es">Arboriforme</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFR02"> <skos:prefLabel xml:lang="pt">Barras Diagonais</skos:prefLabel> <skos:prefLabel xml:lang="en">Diagonal Bars</skos:prefLabel> <skos:prefLabel xml:lang="es">Barras Diagonales</skos:prefLabel> </skos:Concept> </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFR03"> <skos:prefLabel xml:lang="pt">Barras Horizontais</skos:prefLabel> <skos:prefLabel xml:lang="en">Horizontal Bars</skos:prefLabel> <skos:prefLabel xml:lang="es">Barras Horizontales</skos:prefLabel> </skos:Concept> 138 </skos:narrower> <skos:narrower> <skos:Concept rdf:about="MGFR04"> <skos:prefLabel xml:lang="pt">Barras Onduladas</skos:prefLabel> <skos:prefLabel xml:lang="en">Corrugated Bars</skos:prefLabel> <skos:prefLabel xml:lang="es">Barras Onduladas</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF09"> <skos:prefLabel xml:lang="pt">Tectiforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Tectiform</skos:prefLabel> <skos:prefLabel xml:lang="es">Tectiforme</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFT01"> <skos:prefLabel xml:lang="pt">Tectiforme</skos:prefLabel> <skos:prefLabel xml:lang="en">Tectiform</skos:prefLabel> <skos:prefLabel xml:lang="es">Tectiforme</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="MGF10"> <skos:prefLabel xml:lang="pt">Objetos diversos</skos:prefLabel> <skos:prefLabel xml:lang="en">Miscellaneous objects</skos:prefLabel> <skos:prefLabel xml:lang="es">Objetos diversos</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGFOD01"> <skos:prefLabel xml:lang="pt">Vasos</skos:prefLabel> <skos:prefLabel xml:lang="en">Vases</skos:prefLabel> <skos:prefLabel xml:lang="es">Vasos</skos:prefLabel> </skos:Concept> </skos:narrower> </skos:Concept> <!--Motivo-Grupos - Geométrico--> <skos:Concept rdf:about="linkgeometrico"> <skos:prefLabel xml:lang="pt">Geométrico</skos:prefLabel> <skos:prefLabel xml:lang="en">Geometric</skos:prefLabel> <skos:prefLabel xml:lang="es">Geométrico</skos:prefLabel> <skos:narrower rdf:resource="MGG01"/> <skos:narrower rdf:resource="MGG02"/> <skos:narrower rdf:resource="MGG03"/> <skos:narrower rdf:resource="MGG04"/> <skos:narrower rdf:resource="MGG05"/> <skos:broader rdf:resource="linkmotivo_grupos"/> </skos:Concept> <skos:Concept rdf:about="MGG01"> <skos:prefLabel xml:lang="pt">Circular</skos:prefLabel> <skos:prefLabel xml:lang="en">Circular</skos:prefLabel> <skos:prefLabel xml:lang="es">Circular</skos:prefLabel> <skos:narrower> <skos:Concept rdf:about="MGGC01"> <skos:prefLabel xml:lang="pt">Circular</skos:prefLabel> <skos:prefLabel xml:lang="en">Circular</skos:prefLabel> <skos:prefLabel xml:lang="es">Circular</skos:prefLabel> </skos:Concept>