9 Et stabilt klima og ren luft
9.1 Klimaendringer
datasets "Linked Data" internacionais
Uma vez feita a estruturação RDF das amostragens já referidas, foram processados os serviços de reconciliação de alguns dos seus campos com os datasets "Linked Data" internacionais mais divulgados, nomeadamente o Freebase49, a DbPedia50, o Sindice51 e o Geonames52, este último para os dados geográficos.
Apesar de estes datasets estarem disponíveis através de serviços de reconciliação com ligação aos seus respetivos SPARQL Endpoints ou Service API, surgiram dificuldades.
No caso da utilização dos datasets DbPedia, Freebase e Sindice, e decorridos os serviços de reconciliação com os campos de descrição geográficos mais granulares advindos da atomização do campo "Coverage" ‐ como os campos "Município" e
49
A Freebase é uma base de conhecimentos colaborativa, contendo dados criados pelos membros da sua comunidade. Constitui‐se como uma coleção de dados estruturados online recolhidos de várias fontes, incluindo contributos submetidos por utilizadores do Wiki. O seu objetivo assenta na criação de um repositório global que possibilite um acesso mais eficaz à informação, quer por utilizadores quer por máquinas (fonte: https://en.wikipedia.org/wiki/Freebase, consultado em 29 Ago. 2015).
50 A DBpedia consiste num motor de pesquisa que possibilita ao utilizador fazer queries mais complexas
sobre a informação estruturada existente na Wikipedia, incluindo ligações a recursos Linked Data (fonte:
http://pt.dbpedia.org/en/what‐is‐it, consultado em 29 Ago. 2015).
51 O Sindice apresenta‐se como um índice de pesquisa de documentos na Web Semântica. Faz a
indexação da Web Semântica, facultando informação sobre quais as fontes que mencionam um recurso URI, IFP ou palavra‐chave. Este motor de pesquisa não devolve resultados de pesquisa por "triplas", podendo no entanto ser utilizado para procurar fontes de informação RDF relevantes (fonte:
https://www.w3.org/2001/sw/wiki/Sindice, consultado em 29 Ago. 2015).
52
O Geonames consiste numa base de dados geográficos a nível global. Através do seu motor de pesquisa, o utilizador consegue ter acesso à sua base de dados, que contém cerca de 10 milhões de registos de nomes de localidades e cerca de 7,5 milhões de recursos (features). Todos estes recursos encontram‐se distribuídos por 9 classes e depois subdivididos por 645 códigos (feature codes). Para além de disporem dos nomes das localidades em vários idiomas, os seus registos também incluem a latitude, longitude, elevação, população, subdivisões administrativas e códigos postais. Todas as coordenadas aqui indicadas utilizam o sistema referencial geodésico World Geodetic System 1984 (WGS84). Cada recurso aqui providenciado é representado como um recurso web, identificado por um URI estável. Este URI garante o acesso a uma página HTML da Wikipedia ou a uma descrição RDF do recurso, utilizando elementos da ontologia Geonames. Com base nas ligações URL de artigos da
Wikipedia, contidas na descrição destes RDFs, os dados do Geonames estão ligados a registos da DBpedia ou outros recursos em Linked Data RDF (fonte: https://en.wikipedia.org/wiki/GeoNames, consultado em 29 Ago. 2015).
"Localidade", os resultados foram na sua maioria nulos. Tomando como exemplo o caso da localidade "São João da Madeira", este foi confundido por "Gilberto, João " (cantor) pelo dataset DBPedia.
Ainda recorrendo a estes datasets internacionais, e já no caso dos RDFs dos IGT (peças desenhadas e peças escritas), nos campos destinados à indicação dos autores do processo, os resultados da reconciliação com estes datasets foram nulos. Apenas o dataset DBPedia contém registos sobre autores de projetos de arquitetura e urbanismo, mas apenas os mais recentes, como por exemplo, Siza Vieira ou Eduardo Souto de Moura ‐ autores estes que não constam nem nos registos das amostragens e muito menos no espólio do AH‐OTDU até ao presente. Neste sentido, e a fim de poder levar a cabo os testes, foi necessário criar um projeto Open Refine e ficheiro RDF à parte, e depois integrar um novo serviço de reconciliação com base neste RDF, designado por "Autores_OTDU", baseada numa tabela feita (em formato Excel) (Apêndice F), onde constam os nomes dos autores que são referidos nas amostragens e os links para as suas biografias. Poucos links para estas biografias foram recolhidos ‐ a sua recolha fez‐se através de pesquisa geral na web, dado que nem a própria Wikipedia detém estas informações. Foi também consultado o website do motor de pesquisa53 do Ficheiro Nacional de Autoridades Arquivísticas (FNAA)54, onde se verificou que o mesmo ainda não detém estes dados de cariz biográfico sobre autores de projetos de arquitetura e urbanismo do período temporal abrangido pelo AH‐OTDU.
A mesma situação se verificou com os campos destinados a indicar a autoria nos restantes fundos documentais.
No caso específico do dataset Geonames, o seu website não disponibilizava um SPARQL Endpoint directo. Uma vez que seria necessário envidar esforços a nível de programação informática de maior complexidade para se poder ter acesso ao seu
53 Acedido em 28 de Abril de 2015, através do link http://autoridades.arquivos.pt/. 54
O FNAA tem como objetivo garantir a recuperação e o acesso às descrições das diferentes entidades lógicas que o integram, entre as quais entidades produtoras (pessoas coletivas, pessoas singulares e famílias, ativas ou extintas, na sua qualidade de produtoras da documentação de arquivo), entidades detentoras (Arquivos, Bibliotecas, Museus ou quaisquer outras entidades, desde que detentores de documentação de arquivo) e entidades aderentes à Rede Portuguesa de Arquivos (RPA) (fonte:
Service API55, foi criado um serviço de reconciliação com base em ficheiro RDF, utilizando o dataset de Portugal disponibilizado online pelo próprio Geonames. Uma vez adicionado, foi corrido este serviço de reconciliação com o campo "Coverage", do qual nada resultou. Dado que se mantiveram em todas as amostragens os campos "País", "Distrito", Município" e "Localidade" (campos resultantes de uma atomização do campo "Coverage", e que a respetiva informação aqui contida poderá ser considerada como ponto de acesso nominal56), estes foram de seguida submetidos ao mesmo processo de reconciliação ‐ que em nada resultou também. Daqui se deduz que eventualmente, a sua reconciliação só seria possível quando feita através de outros recursos de programação mais avançados, e após integração dos RDFs do AH‐ OTDU nas bases de dados do Portal Europeana. A fim de tentar continuar os testes, foi necessário criar um projeto e ficheiro RDF à parte e depois integrar um novo serviço de reconciliação com base neste RDF, denominado "Geonames_Select_Link", baseada numa tabela feita (Apêndice G), que inclui a indicação dos permalinks57 (na sua maioria com o nível "Admin1") para cada localidade, obtidos manualmente através de pesquisa no próprio website do Geonames.org.
Face a estes resultados de reconciliação com datasets internacionais, e no seguimento do já executado para a reconciliação de dados dos campos de descrição destinados à autoria dos processos e aos dados geográficos, foram criados mais serviços de reconciliação com base nos RDFs provenientes dos projetos Open Refine
dos próprios fundos documentais em análise, passando a partir daqui a serem os testes operacionalizados em circuito interno. Com base nestes novos serviços, foram feitos novos testes de reconciliação.
55 API corresponde ao acrónimo de Application Programming Interface. No contexto do dataset
Geonames, o Service API constitui‐se como uma funcionalidade, disponível para programadores, através do qual estes conseguem criar aplicações que possam aceder a funcionalidades do serviço Geonames. O acesso, consulta e extração de conteúdos deste dataset podem assim ser feitos de uma forma automatizável por programação.
56
ODA, v.2, pg. 196 ‐ A entidade geográfica pode ser considerada um ponto de acesso nominal.
Assim sendo, para o projeto Open Refine dos IGT ‐ Peças desenhadas (total de 174 registos), os resultados foram: Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos
Plano_Nome IGT_Peças Escritas 82% 18% Plano_Nome_Recon_PEscritas Autor_Nome Autores_OTDU 22% 78% AutorNome_ReconResult_Autor
es_OTDU Coverage Geonames_Select
_Link
0% 100% Não foi criado novo campo para acolher este resultado
Municipio Geonames_Select _Link
100% 0% Municipio_Recon_GeonamesSele ct
Municipio Fotos Aéreas 10% 90% Municipio_Recon_FotosAereas Localidade Geonames_Select
_Link
88% 12% Localidade_Recon_GeonamesSel ect
Localidade Fotos Aéreas 10% 90% Localidade_Recon_FotosAereas Tabela 5: IGT ‐ Peças desenhadas ‐ Resultados do processamento de serviços de reconciliação de dados, através do software OpenRefine No projeto Open Refine dos IGT ‐ Peças escritas (total de 186 registos), os resultados foram: Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Plano_Nome IGT_Peças Desenhadas 54% 46% Plano Nome_ReconcResult_PD
Autor_Nome Autores_OTDU 10% 90% AutorNome_ReconResult_Autor esOTDU
Coverage Geonames_Select _Link
0% 100% Não foi criado novo campo para acolher este resultado
Municipio Geonames_Select _Link
100% 0% Municipio_Recon_GeonamesSele ct
Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Localidade Geonames_Select _Link 70% 30% Localidade_Recon_GeonamesSel ect
Localidade Fotos Aéreas 0% 100% Não foi criado novo campo para acolher este resultado
Tabela 6: IGT‐Peças escritas ‐ Resultados do processamento de serviços de reconciliação de dados, através do software OpenRefine
Cumpre aqui referir que, para estas duas amostragens, foram obtidos melhores resultados com a reconciliação dos campos de descrição que reportassem aos dados geográficos, atomizados do campo de descrição "Coverage" (os campos "Municipio" e "localidade") e com os serviços RDF criados a partir da tabela criada com os links Geonames. Para o projeto Open Refine dos EUC (total de 14 registos), os resultados foram: Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Plano_Nome Geonames_Select _Link
0% 100% Não foi criado novo campo para acolher este resultado
Coverage Geonames_Select _Link
0% 100% Não foi criado novo campo para acolher este resultado
Municipio Geonames_Select _Link
100% 0% Municipio_GeonamesLink_Recon cResult
Municipio Fotos Aéreas 28% 72% Municipio_Recon_FotosAereas Localidade Geonames_Select
_Link
100% 0% Localidade_GeonamesLink_Reco ncResult
Localidade Fotos Aéreas 22% 78% Localidade_Recon_FotosAereas Tabela 7: EUC ‐ Resultados do processamento de serviços de reconciliação de dados, através do
software OpenRefine
De referir que, nesta amostragem não existe o campo "Autor_Nome" mas sim o campo "entidade_peticionária", com dados completamente distintos. Devido a este facto, este campo não foi submetido a reconciliação de dados.
À semelhança do que ocorreu com as amostragens dos IGT, neste fundo foram novamente obtidos melhores resultados com a reconciliação dos campos de descrição referentes aos dados geográficos, resultantes da atomização do campo de descrição "Coverage" (os campos "Municipio" e "localidade") e com os serviços RDF criados a partir da tabela criada com os links Geonames. No projeto Open Refine das peças fotográficas dos álbuns (total de 56 registos), os resultados foram: Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Plano_Nome IGT_Peças Desenhadas
0% 100% Não foi criado novo campo para acolher este resultado
EUC_Select_Equip 0% 100% Não foi criado novo campo para acolher este resultado
Coverage Geonames_Select _Link
0% 100% Não foi criado novo campo para acolher este resultado
Municipio Geonames_Select _Link
100% 0% Municipio_GeonamesLink_Recon cResult
Municipio Fotos Aéreas 25% 75% Municipio_Recon_FotosAereas Localidade Geonames_Select
_Link
100% 0% Localidade_GeonamesLink_Reco ncResult
Localidade Fotos Aéreas 16% 84% Localidade_Recon_FotosAereas Unidades de
descrição relacionadas
EUC_Select_Equip 0% 100% Não foi criado novo campo para acolher este resultado
Tabela 8: Peças dos álbuns fotográficos ‐ Resultados do processamento de serviços de reconciliação de dados, através do software OpenRefine
Mais uma vez, e à semelhança das amostragens anteriores, os melhores foram obtidos nos mesmos campos de descrição geográfica com os mesmos serviços RDF atrás referidos. Reportaram‐se no entanto dificuldades em reconciliar com o serviço RDF criado a partir das amostragens dos fundos documentais dos IGT e dos EUC. Ao tentar fazer a reconciliação de dados do campo "Plano_Nome" com o serviço de reconciliação "IGT‐Peças Desenhadas", pretendeu‐se testar se o mesmo seria possível,
tendo por base a indicação geográfica referida na designação do processo, mesmo sabendo que os processos são distintos entre si. No caso da reconciliação de dados do campo "Plano_Nome" com o serviço de reconciliação " EUC_Select_Equip", o mesmo foi feito tendo por base duas indicações ‐ a localização geográfica e a tipologia de EUC ‐ presentes na designação do processo.
Para além do campo "Plano_Nome", foi também tentado reconciliar estes serviços RDF com o campo "Unidades de Descrição relacionadas" (sugerido pelas ISAD(G)), mas não foram obtidos resultados na mesma.
A provável razão poder‐se‐á prender com o facto de o conteúdo destes campos não ser coincidente, ou seja, reportam ao mesmo processo mas a sua designação não coincide. Outra causa poder‐se‐á prender com o excesso de informação contida nos campos de descrição, feitos conforme o estipulado nas ISAD(G): o software em utilização não é capaz de identificar palavras avulsas, identifica apenas a célula toda.
Neste caso, atomizar a informação contida nestes campos e distribui‐la por mais campos poderia ser a solução – como já confirmado com a reconciliação dos campos "Municipio" e "Localidade" (atomização do campo "Coverage"). No entanto, e conforme os casos, tal poderia resultar num número infindável de campos. Seguindo esta opção, aumentar‐se‐ia a complexidade do motor de pesquisa e das estruturas das suas queries, necessárias para devolver e apresentar estes resultados ao utilizador, uma vez que seria necessário contemplar todos os campos. Para o projeto Open Refine das peças fotográficas aéreas (total de 17 registos), os resultados foram: Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Plano_Nome Geonames_Select _Link 100% 0% Plano_Nome_GeonamesLink_Re concResult Coverage Geonames_Select _Link
0% 100% Não foi criado novo campo para acolher este resultado
Concelho Geonames_Select _Link
100% 0% Concelho_GeonamesLink_Recon cResult
Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Localidade Geonames_Select _Link 100% 0% Localidade_GeonamesLink_Reco ncResult Tabela 9: Peças fotográficas aéreas ‐ Resultados do processamento de serviços de reconciliação de dados, através do software OpenRefine
Cumpre aqui referir que, ao proceder à reconciliação do campo "Plano_Nome"58 com o serviço de reconciliação "Geonames_Select_Link", foi testada a opção de correção sugerida pelo software Open Refine, nos casos dos registos dos voos feitos em Évora em datas diferentes. A aplicação desta opção resultou em perda de informação nestes registos ‐ manteve‐se a indicação da localidade a que o voo reportava, mas perdeu‐se a indicação do número de voo, informação que ajudava a fazer a distinção entre estes registos. Neste sentido, é de considerar a criação de um novo campo que detenha por si só a informação do número de voo, ou então neste caso específico ignorar a opção sugerida pelo software, uma vez que a reconciliação dos campos "Municipio" e "Localidade" com o serviço de reconciliação "Geonames_Select_Link" já cobrem a totalidade dos registos. No projeto Open Refine dos artigos do fundo bibliográfico (total de 9 registos), os resultados foram: Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Plano_Nome IGT_Peças Desenhadas
0% 100% Não foi criado novo campo para acolher este resultado
Autor_Nome Autores_OTDU 89% 11% AutorNome_ReconResult_Autor esOTDU
Coverage Geonames_Select _Link
0% 100% Não foi criado novo campo para acolher este resultado 58 A designação original deste campo era "título". A sua designação foi alterada para "Plano_Nome", a fim de a sua estrutura RDF estar consonante com as das outras amostragens.
Campos submetidos a reconciliação de dados Serviço de reconciliação de dados utilizado Resultados obtidos Novo campo criado (resultado da reconciliação) Reconciliados Nulos Municipio Geonames_Select _Link 11% 89% Municipio_GeonamesLink_Recon cResult Localidade Geonames_Select _Link 11% 89% Localidade_GeonamesLink_Reco ncResult Tabela 10: Artigos do fundo bibliográfico ‐ Resultados do processamento de serviços de reconciliação de dados, através do software OpenRefine
No que reporta ao resultado nulo da tentativa de reconciliação feita para o campo "Plano_Nome" com o serviço de reconciliação "IGT_Peças Desenhadas", esta deveu‐se ao facto de a estrutura do RDF que deu origem a este serviço assentar no objeto em si (as peças desenhadas) e não no processo em si (o Plano). Neste sentido, e para colmatar esta situação, seria necessário autonomizar a informação desta unidade de instalação (o Plano), tendo uma webpage própria para cada processo, onde estariam replicados os links para as suas peças processuais, á semelhança do que ocorre no formato analógico. Tendo esta autonomização, e como já referido, seria assim mais fácil estruturar um ficheiro RDF e serviço de reconciliação próprio que eventualmente pudesse estabelecer ligações com o campo "Plano_Nome" presente nas amostragens.
No caso do resultado obtido da reconciliação feita para o campo "Autor_Nome" com o serviço de reconciliação "Autores_OTDU", cumpre alertar que nem todos os autores dos artigos selecionados estavam contemplados na listagem que deu origem ao RDF dos "Autores_OTDU".
Nos casos dos resultados obtidos da reconciliação feita para os campos "Municipio" e "Localidade" com o serviço de reconciliação "Geonames_Select_Link", para além de alertar que nem todos os artigos detinham a indicação do município a que reportavam, existiam também situações extremas que não foram aceites pelo software. Uma destas situações prende‐se com o registo do artigo identificado como PT/DGT/MOPC/DGSU/DGSU‐RevUrb01/RevUrb‐Art00001, em que no campo de descrição "Municipio" consta a indicação dos municípios abrangidos (vide Apêndice C):
Amarante; Baião; Felgueiras; Gondomar; Lousada; Maia; Marco de Canaveses; Matosinhos; Paços de Ferreira; Paredes; Penafiel; Porto; Póvoa de Varzim; Santo Tirso; Valongo; Vila do Conde; Vila Nova de Gaia; Amares; Barcelos; Braga; Cabeceiras de Basto; Esposende; Fafe; Guimarães; Póvoa de Lanhoso; Terras de Bouro; Vieira do Minho; Vila Nova de Famalicão; Vila Verde; Arcos de Valdevez; Caminha; Melgaço; Monção; Paredes de Coura; Ponte da Barca; Ponte de Lima; Valença; Viana do Castelo; Vila Nova de Cerveira; Arouca; Castelo de Paiva; Espinho; Santa Maria da Feira; Oliveira de Azeméis; Ovar; São João da Madeira; Vale de Cambra; Cinfães; Resende.
Neste caso específico, e mesmo que o software aceitasse esta dimensão de caracteres, a sua reconciliação de dados seria também difícil, pelas razões já apresentadas anteriormente ‐ a muita informação contida neste campo. Como já referido, uma solução provável seria distribuir e isolar cada referência de município em seu campo (Ex: Municipio_01, Municipio_02, Municipio_NN), a fim de ser mais fácil a sua reconciliação. Mas neste caso em especial, tal resultaria num aumento considerável do número de campos (mais quarenta e nove), e eventualmente numa maior complexidade em estruturar o seu RDF, a sua query em SPARQL e a apresentação dos resultados de pesquisa ao utilizador.
4.3. Considerações sobre a fase de experiências com as queries de teste