mariana curado malta contributo metodológico para o

Mar

iana

Cur

ado

Mal

ta

Maio de 2014UMin

ho |

201

4C

ontr

ibut

o m

etod

ológ

ico

para

o d

esen

volv

imen

to d

epe

rfis

de

aplic

ação

no

cont

exto

da

Web

Sem

ântic

a

Universidade do MinhoEscola de Engenharia

Mariana Curado Malta

Contributo metodológico para odesenvolvimento de perfis deaplicação no contexto da Web Semântica

Maio de 2014

Tese de DoutoramentoTecnologias e Sistemas de Informação

Trabalho efectuado sob a orientação deProfessora Doutora Ana Alice BaptistaProfessora Doutora Cristina Parente

Mariana Curado Malta

Contributo metodológico para odesenvolvimento de perfis deaplicação no contexto da Web Semântica

Universidade do MinhoEscola de Engenharia

Agradecimentos

O caminho que percorremos durante um doutoramento é solitário, dizem, mas na realidade elefoi um lugar de muitos encontros - e de muita alegria. Um doutoramento não se faz sozinho, otítulo será meu, mas é partilhado com todos o que aqui nomeio. Agradeço:

Aos meus pais, por toda a sua generosidade.

À Ana Alice, orientadora e amiga. Pela caminhada maravilhosa que fizemos juntas. Porse dar tanto no trabalho que executa. Por me moldar e por fazer de mim uma pessoa maiselevada intelectualmente. Por entender as minhas manias e fraquezas, e por saber contorná-las.Pela muita e muita paciência; pelas revisões exaustivas - momentos de grande aprendizagem ecrescimento. Ana Alice: Foram 4 anos cheios, com tanta descoberta e tanto desafio maravilhoso!- jamais esquecerei.

À Cristina, que não hesitou nem um segundo em aceitar o meu pedido de co-orientação. Acom-panhou-me neste percurso de uma forma muito solidária e amiga. Sempre presente no momentocerto, acreditando em mim desde o momento zero.

À Ida pela sua infinita disponibilidade e generosidade. Querida amiga: que faria eu semti?. À Matilde pela revisão exaustiva e meticulosa da versão final da Tese.

Aos companheiros do consórcio RIPESS, que me fizeram uma deles, e que depois confiaram emmim para os liderar no processo DCAP-ESS. Na primeira fase: Agnès Gyolai, Carlos Rey, DanielTygel, Dominique Guardiola, Eric Lavillunière, Flo Ledermann, Jason Nardi, Marc Alphandery,Nancy Neamtan e Carole Lèsveque; na segunda fase: Alan Tygel, Daniel Tygel, Craig Borowiake Jason Nardi. Queridos companheiros: Continuaremos juntos neste desejo de tornar o mundoum lugar mais solidário e mais justo. Onde reine o equilíbrio justo de desejos e posses, e nãouma competição desenfreada.

Aos entrevistados “DCAP”, que não posso nomear para manter a sua confidencialidade. Pelapaciência que tiveram em rever processos já realizados há tantos anos, dando um contributoinestimável ao meu trabalho. Aos participantes do Focus Group que não posso nomear paramanter a sua confidencialidade. Pessoas tão sábias e tão sensatas. Enriqueceram enormemente omeu trabalho.

À Eva Méndez, à Jane Greenberg e ao Tom Baker; pessoas com as quais me cruzei nestepercurso e que com a sua sabedoria e simpatia me tocaram. De uma ou de outra forma pararampara me VER e me dar incentivo e energia muito positiva. Ao Alberto Simões do DI da Escolade Engenharia da Universidade do Minho pela ajuda inestimável no LATEX. Ao departamentoDSI da Escola de Engenharia da Universidade do Minho, personificada nos seus funcionários,professores e colegas PDTSI. É um lugar de excepção, com imensa liberdade e companheirismo.

Ao Artur, o melhor Shiatsu-man da galáxia.

À Teresa e ao Luís pela hospitalidade em Guimarães. Queridos amigos: A vossa casa é um lugarde tranquilidade e segurança onde me senti sempre bem!

À Zé, pela casa em Carreço, lugar de paz e de sossego longe da rotina dos dias. E obri-gada por tudo o resto, que não é nada pouco.

Contributo metodológico para o desenvolvimento de perfis de aplicação no contextoda Web semântica

ResumoA Web Semântica (WS) é um paradigma da Web que surgiu com o intuito de ligar dados,permitindo a partilha de conteúdos para além das fronteiras das aplicações e dos sítios Web.Neste contexto, um perfil de aplicação de metadados (PA) é um constructo genérico para desenharregistos de metadados que satisfazem necessidades específicas das aplicações, proporcionandointeroperabilidade semântica com outras aplicações. Esse desenho dos registos de metadadostem como base vocabulários e modelos definidos globalmente pela comunidade de metadados.

A Dublin Core Metadata Initiative, provavelmente a mais conhecida e mais importanteiniciativa a nível mundial no que diz respeito a metadados, definiu um modelo abstracto (DublinCore Abstract Model) onde um dos constructos é o Dublin Core Aplication Profile (DCAP). ADCMI refere que a utilização de um DCAP é essencial para implementar interoperabilidade nocontexto da WS.

A concepção, o desenvolvimento e a implementação de modelos, sendo um processo complexo,necessitam de um suporte metodológico; um DCAP não foge a essa regra. Por essa razão,realizámos o estudo do estado da arte dos métodos para o desenvolvimento de PA, com o sentidode fazer o levantamento das práticas da comunidade de metadados no desenvolvimento de PA.Este estudo revelou que até à data não existe nenhum método para o desenvolvimento de um PAou DCAP. O objectivo deste projecto de doutoramento foi o de fornecer um primeiro contributopara um tal método.

A concepção do Method for the develoment of DCAP (Me4DCAP) teve como suporte: (i) asprimeiras fases (até à modelação de dados) dos métodos de desenvolvimento de software; (ii) osresultados de entrevistas realizadas a desenvolvedores DCAP; (iii) as práticas identificadas noestudo já referido do estado da arte dos métodos para desenvolvimento de PA. O Me4DCAPtem como base o Singapore Framework for DCAP, e como ponto de partida o Rational UnifiedProcess, um dos mais conhecidos e utilizados processos de desenvolvimento de software.

Para realizar o nosso trabalho utilizámos a metodologia de investigação Design ScienceResearch (DSR), no enquadramento particular para a área dos Sistemas de Informação dostrês ciclos de Hevner (2007). Este enquadramento define a possibilidade da utilização de umasituação real, a que Hevner chama de “situação experimental”, para a execução de ciclos deconstrução-avaliação, onde o artefacto em construção - no nosso caso o Me4DCAP - vai sendoavaliado na situação experimental e redefinido, num processo iterativo. A situação experimentalpor nós utilizada foi o desenvolvimento de um DCAP para os Sistemas de Informação Web dacomunidade mundial de Economia Social e Solidária (ESS). Esse desenvolvimento foi realizadoconjuntamente com um grupo que saiu do seio da comunidade da ESS mundial. Este trabalho,identificado como uma oportunidade, resultou num DCAP-ESS.

O Me4DCAP foi validado através de um grupo de discussão integrado numa conferência daespecialidade, e ainda através de um Focus Group com sete especialistas mundiais de metadados.

Como resultados deste doutoramento obtivemos o Me4DCAP V1.0 e o DCAP-ESS V 1.0.

Palavras-chave: Metadados; Web Semântica; Perfil de Aplicação; Dublin Core ApplicationProfile; Me4DCAP, Métodos; Interoperabilidade Semântica; Economia Social e Solidária

Methodological contribution to the development of application profiles in the con-text of the semantic Web

AbstractThe Semantic Web (SW) is a Web paradigm that emerged with the aim of linking data, enablingcontent share beyond the borders of Web applications and Web sites. In this context, a metadataapplication profile (AP) is a generic construct to design metadata records that satisfy specificneeds of the applications, enabling semantic interoperability with other applications. Thismetadata record design is based on vocabularies and models globally defined by the metadatacommunity.

The Dublin Core Metadata Initiative (DCMI), probably the best known and most importantglobal initiative with regard to metadata, defined an abstract model (Dublin Core AbstractModel) where one of its constructs is the Dublin Core Application Profile (DCAP). DCMI statesthat the use of a DCAP is very important in order to implement interoperability in the contextof the SW.

The conception, development and implementation of models need a methodological supportsince they are complex processes. Therefore, in order to understand the metadata communitypractices in the development of AP, we performed the study of the state of the art of the methodsfor the development of AP. This study revealed that until now there is no method for thedevelopment of an AP. The goal of this PhD project was to develop a first approach to such amethod.

The design of the Method for the development of DCAP (Me4DCAP) had as support: (i)the first stages (up to the data modeling) of software development; (ii) the results of interviewsconducted to DCAP developers, (iii) the practices identified in the state of the art of the methodsfor AP development. Me4DCAP is based on the Singapore Framework for DCAP, and has asstarting point the Rational Unified Process, one of the best known and most used softwaredevelopment processes.

We used the research methodology Design Science Research (DSR) in our work, and the“three cycles” Information Systems specific framework defined by Hevner (2007). This frameworkdefines the possibility of using a real situation, called by Hevner (2007) as the “experimentalsituation”, for the execution of the construction-evaluation cycles. In these cycles the artifact indevelopment – in our case Me4DCAP – is being evaluated in the experimental situation, andwith the feedbacks from this evaluation, it is redefined, in an iterative process. The experimentalsituation we used was the development of a DCAP for the Web based information systems of theSocial Solidarity Economy (SSE) world community (DCAP-SSE). The DCAP-SSE developmentwas jointly undertaken with a group from the world SSE community. This work, identified as anopportunity, resulted in a DCAP-SSE V1.0.

The Me4DCAP was validated through a discussion group integrated in a metadata communityinternational conference, and in a Focus Group with seven metadata world experts.

This PhD has as results the Me4DCAP V1.0 and the DCAP-SSE V 1.0.

Keywords: Metadata; Semantic Web; Dublin Core Application Profile; Me4DCAP, Methods;Semantic Interoperability; Social and Solidarity Economy

Pelo sonho é que vamos(...)

Chegamos? Não chegamos?Partimos. Vamos. Somos.

Sebastião da Gama

Conteúdo

Lista de tabelas xiii

Lista de figuras xvii

Lista de acrónimos xxi

Opções de normalização e de grafia xxiii

1 Introdução 11.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problema e oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivação e pertinência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 Na área científica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.2 Na situação experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Natureza e âmbito do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Organização da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Fundamentos teóricos e estado da arte 72.1 Metodologia de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Estratégias de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Análise de conteúdo - estado da arte dos métodos para o desenvolvimento

de um Perfil de Aplicação de metadados . . . . . . . . . . . . . . . . . . . 92.2 Fundamentos teóricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Web semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Metadados e esquemas de metadados . . . . . . . . . . . . . . . . . . . . . 112.2.3 Perfil de Aplicação de metadados e interoperabilidade semântica . . . . . 16

2.3 Estado da arte - métodos para o desenvolvimento de um Perfil de Aplicação demetadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.2 Âmbito do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.3 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.4 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Metodologia de investigação 353.1 Breve resenha sobre metodologias de investigação . . . . . . . . . . . . . . . . . . 353.2 Design Science Research - Fundamentação . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Design Science Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

ix

Conteúdo

3.2.2 Enquadramento metodológico da Design Science Research: os três ciclosde Hevner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 Aplicação dos três ciclos de Hevner no caso de investigação . . . . . . . . . . . . 423.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Detalhe da aplicação dos três ciclos de Hevner 454.1 Espaço Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Resultados do estudo do estado da arte dos métodos para o desenvolvimentode um Perfil de Aplicação de metadados . . . . . . . . . . . . . . . . . . . 46

4.1.2 Entrevistas a desenvolvedores de Dublin Core Application Profiles . . . . 484.1.3 Validação do Método para o Desenvolvimento de Dublin Core Application

Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Espaço Knowlegde Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.1 Análise dos métodos para o desenvolvimento de software . . . . . . . . . . 634.3 Espaço Design Science Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.3.1 Processo de construção do Método para o Desenvolvimento de Dublin CoreApplication Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.3.2 Situação experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.4 Resumo do processo de construção do Método para o Desenvolvimento de Dublin

Core Application Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.5 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5 Resultados - método para o desenvolvimento de um Dublin Core ApplicationProfile 995.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.2 A equipe de trabalho de desenvolvimento do Dublin Core Application Profile . . 1025.3 Desenvolver os Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 1065.4 Desenvolver o Modelo de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.5 Desenvolver o Description Set Profile . . . . . . . . . . . . . . . . . . . . . . . . . 1115.6 Desenvolver os Guias de Utilização . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.7 Desenvolver os Guias de Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.8 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6 Situação experimental: um perfil de aplicação para a Economia Social e Soli-dária 1216.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.2 Desenvolver os Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.2.1 Documento Visão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.2.2 Estado da arte do contexto de aplicação . . . . . . . . . . . . . . . . . . . 1256.2.3 Requisitos de alto-nível . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506.2.4 Modelo de Casos-de-Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506.2.5 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.3 Desenvolver o Modelo de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . 1536.3.1 Environmental Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536.3.2 Modelo de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

6.4 Desenvolver o Description Set Profile . . . . . . . . . . . . . . . . . . . . . . . . . 1686.4.1 Modelo de Dados Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.4.2 Alinhamento de Vocabulários . . . . . . . . . . . . . . . . . . . . . . . . . 1766.4.3 Matriz de Restrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.4.4 Description Set Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

x Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Conteúdo

6.5 Desenvolver os Guias de Utilização e os Guias de Sintaxe . . . . . . . . . . . . . 2256.6 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

7 Considerações finais 2277.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2277.2 Principais Contributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2287.3 Limitações do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2307.4 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Bibliografia 233

Apêndice A Análise preliminar dos Sistemas de Informação Web da EconomiaSocial e Solidária 247

Apêndice B Relato dos trabalhos com o grupo da Economia Social e Solidária 251B.1 Fase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

B.1.1 Resultados reunião de Paris . . . . . . . . . . . . . . . . . . . . . . . . . . 252B.1.2 Resumo das entrevistas a líderes da Econoia Social e Solidária . . . . . . 255B.1.3 Guião das entrevistas líderes da Economia Social e Solidária . . . . . . . . 257

B.2 Fase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Apêndice C Análise dos Perfis de Aplicação de metadados 267C.1 Lista dos Perfis de Aplicação de metadados analisados por domínio de aplicação 267C.2 Perfis de Aplicação de metadados analisados - Linha do tempo . . . . . . . . . . 271C.3 Matriz I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

C.3.1 Perfis de Aplicação de metadados excluídos do estudo . . . . . . . . . . . 321C.4 Matriz II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323C.5 Matriz III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Apêndice D Guião das entrevistas a desenvolvedores Dublin Core ApplicationProfile 349

Apêndice E Base de conhecimento utilizada para a concepção do Method forthe Development of Dubin Core Application Profiles 351

Apêndice F Grupo de discussão de validação do Method for the Developmentof Dubin Core Application Profiles V0.1 357F.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357F.2 Transcrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357F.3 Email convite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Apêndice G Focus Group de validação do Method for the Development of DubinCore Application Profiles V0.2 363G.1 Definição do Focus Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363G.2 Documento convite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364G.3 Inquérito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica xi

Conteúdo

xii Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Lista de Tabelas

2.1 A evolução do conceito de Perfil de Aplicação de metadados na comunidade demetadados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Sumário dos resultados obtidos na análise do estado da arte dos métodos dedesenvolvimento de Perfis de Aaplicação de metadados. . . . . . . . . . . . . . . 31

4.1 Resultados do estado da arte das metodologias para o desenvolvimento de Perfisde Aplicação de metadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Lista das entrevistas realizadas a desenvolvedores de Dublin Core ApplicationProfiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Características socio-demográficas e escolares dos participantes do FG. . . . . . . 544.4 Características profissionais dos participantes do Focus Group. . . . . . . . . . . 58

6.1 Lista das entrevistas exploratórias Réseaux Intercontinental de Promotion delÉconomie Sociale Solidaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.2 Links das entrevistas exploratórias Réseaux Intercontinental de Promotion delÉconomie Sociale Solidaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.3 Características do Sistemas de Informação Web zoes.it | Itália . . . . . . . . . . . 1406.4 Características do Sistemas de Informação Web la-bdis.org | França . . . . . . . . 1416.5 Características do Sistemas de Informação Web ecocolux.lu | Luxemburgo . . . . 1436.6 Características do Sistemas de Informação Web economiasolidaria.org | Espanha 1436.7 Características do Sistemas de Informação Web vivirbien.mediavirus.org | Austria 1456.8 Características do Sistemas de Informação Web economiesocialequebec.ca | Canada1466.9 Características do Sistemas de Informação Web cirandas.net | Brasil . . . . . . . 1466.10 Categorização do tipo de instituições ou comunidades que desenvolveram o Perfil

de Aplicação de metadados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566.11 Categorização domínios de aplicação dos Perfis de Aplicação de metadados. . . . 1576.12 Categorização dos esquemas de metadados . . . . . . . . . . . . . . . . . . . . . . 1586.13 Percentagem dos Perfis de Aplicação de metadados por Tipo de Instituição. . . . 1616.14 Percentagem dos Perfis de Aplicação de metadados por domínio. . . . . . . . . . 1616.16 Percentagem de esquemas de metadados produzidos por domínio de aplicação. . 1656.17 Alinhamento de Vocabulários Dublin Core Application Profile - Economia Social

e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.18 Crosswalk rdfs:subclassOf do vocabulário ESSGlobal V1.0. . . . . . . . . . . . . . 1936.19 Crosswalk owl:equivalentProperty do vocabulário ESSGlobal V1.0. . . . . . . . . 1966.20 Os esquemas de codificação de vocabulário desenvolvidos para servir o Dublin

Core Application Profile-Economia Social e Solidária . . . . . . . . . . . . . . . . 210

B.1 Listas controladas de termos definidas pelo consórcio. . . . . . . . . . . . . . . . 253B.2 Reuniões consórcio-Réseaux Intercontinental de Promotion de lÉconomie Sociale

Solidaire e resultados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

xiii

Lista de Tabelas

B.3 Conclusões das entrevistas exploratórias Réseaux Intercontinental de Promotionde l’Économie Social Solidaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

C.1 Perfis de aplicação de metadados analisados . . . . . . . . . . . . . . . . . . . . . 271C.2 Categorização dos Perfis de Aplicação de metadados . . . . . . . . . . . . . . . . 275C.3 Lista dos Perfis de Aplicação Analisados no domínio da Agricultura . . . . . . . 275C.4 Perfil de Aplicação de metadados AGRIS . . . . . . . . . . . . . . . . . . . . . . 276C.5 Perfil de Aplicação de metadados Organization AP . . . . . . . . . . . . . . . . 276C.6 Perfil de Aplicação de metadados FiMES . . . . . . . . . . . . . . . . . . . . . . 277C.7 Perfil de Aplicação de metadados Ag-Event . . . . . . . . . . . . . . . . . . . . . 277C.8 Perfil de Aplicação de metadados Ag-Job AP . . . . . . . . . . . . . . . . . . . . 278C.9 Lista dos Perfil de Aplicação de metadados de metadados no domínio das Biblio-

tecas/Repositórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279C.10 Perfil de Aplicação de metadados RENAP . . . . . . . . . . . . . . . . . . . . . . 280C.11 Perfil de Aplicação de metadados DC-LIB . . . . . . . . . . . . . . . . . . . . . . 280C.12 Perfil de Aplicação de metadados NLM MS . . . . . . . . . . . . . . . . . . . . . 281C.13 Perfil de Aplicação de metadados Michael-eu DCAP . . . . . . . . . . . . . . . . 281C.14 Perfil de Aplicação de metadados DC-CDAP . . . . . . . . . . . . . . . . . . . . 282C.15 Perfil de Aplicação de metadados MAP . . . . . . . . . . . . . . . . . . . . . . . 282C.16 Perfil de Aplicação de metadados OAI-DC . . . . . . . . . . . . . . . . . . . . . . 283C.17 Perfil de Aplicação de metadados TDL ETD MODS . . . . . . . . . . . . . . . . 283C.18 Perfil de Aplicação de metadados MPEG-21 DIDL . . . . . . . . . . . . . . . . . 284C.19 Perfil de Aplicação de metadados DRC AP . . . . . . . . . . . . . . . . . . . . . 284C.20 Lista dos Perfil de Aplicação de metadados no domínio da Ciência . . . . . . . . 285C.21 Perfil de Aplicação de metadados SWAP . . . . . . . . . . . . . . . . . . . . . . . 285C.22 Perfil de Aplicação de metadados APIARY AP . . . . . . . . . . . . . . . . . . . 286C.23 Perfil de Aplicação de metadados DRYAD . . . . . . . . . . . . . . . . . . . . . . 286C.24 Perfil de Aplicação de metadados MLAP . . . . . . . . . . . . . . . . . . . . . . . 287C.25 Lista dos Perfis de Aplicação no domínio de E-Government . . . . . . . . . . . . 288C.26 Perfil de Aplicação de metadados GO-WMES . . . . . . . . . . . . . . . . . . . . 288C.27 Perfil de Aplicação de metadados DC-Gov AP . . . . . . . . . . . . . . . . . . . . 289C.28 Perfil de Aplicação de metadados e-GMS . . . . . . . . . . . . . . . . . . . . . . . 289C.29 Perfil de Aplicação de metadados PSI AP . . . . . . . . . . . . . . . . . . . . . . 290C.30 Perfil de Aplicação de metadados OWMS . . . . . . . . . . . . . . . . . . . . . . 290C.31 Perfil de Aplicação de metadados ADMS . . . . . . . . . . . . . . . . . . . . . . . 291C.32 Lista dos Perfis de Aplicação do domínio Multi-Domínio . . . . . . . . . . . . . . 292C.33 Perfil de Aplicação de metadados NZGLS . . . . . . . . . . . . . . . . . . . . . . 293C.34 Perfil de Aplicação de metadados DC-EM . . . . . . . . . . . . . . . . . . . . . . 293C.35 Perfil de Aplicação de metadados Audovisual AP . . . . . . . . . . . . . . . . . . 294C.36 Perfil de Aplicação de metadados TBM-AP . . . . . . . . . . . . . . . . . . . . . 294C.37 Perfil de Aplicação de metadados VMAP . . . . . . . . . . . . . . . . . . . . . . 295C.38 Perfil de Aplicação de metadados AGLS MS . . . . . . . . . . . . . . . . . . . . . 295C.39 Lista dos Perfis de Aplicação do domínio Objectos de Aprendizagem . . . . . . . 296C.40 Perfil de Aplicação de metadados ANZ LOM . . . . . . . . . . . . . . . . . . . . 298C.41 Perfil de Aplicação de metadados FAILTE . . . . . . . . . . . . . . . . . . . . . . 299C.42 Perfil de Aplicação de metadados Celebrate AP . . . . . . . . . . . . . . . . . . . 299C.43 Perfil de Aplicação de metadados CanCore AP . . . . . . . . . . . . . . . . . . . 300C.44 Perfil de Aplicação de metadados FERL . . . . . . . . . . . . . . . . . . . . . . . 300C.45 Perfil de Aplicação de metadados HLSI . . . . . . . . . . . . . . . . . . . . . . . 301C.46 Perfil de Aplicação de metadados LOMAP . . . . . . . . . . . . . . . . . . . . . . 301

xiv Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Lista de Tabelas

C.47 Perfil de Aplicação de metadados ManUel . . . . . . . . . . . . . . . . . . . . . . 302C.48 Perfil de Aplicação de metadados OpenCartable . . . . . . . . . . . . . . . . . . . 302C.49 Perfil de Aplicação de metadados UK LOM Core . . . . . . . . . . . . . . . . . . 303C.50 Perfil de Aplicação de metadados SCORM . . . . . . . . . . . . . . . . . . . . . . 303C.51 Perfil de Aplicação de metadados Ag-LR . . . . . . . . . . . . . . . . . . . . . . . 304C.52 Perfil de Aplicação de metadados AraCore . . . . . . . . . . . . . . . . . . . . . . 304C.53 Perfil de Aplicação de metadados NORMLOM . . . . . . . . . . . . . . . . . . . 305C.54 Perfil de Aplicação de metadados TLF AP . . . . . . . . . . . . . . . . . . . . . . 305C.55 Perfil de Aplicação de metadados MIMETA . . . . . . . . . . . . . . . . . . . . . 306C.56 Perfil de Aplicação de metadados Edna . . . . . . . . . . . . . . . . . . . . . . . 306C.57 Perfil de Aplicação de metadados DC-Edu . . . . . . . . . . . . . . . . . . . . . . 307C.58 Perfil de Aplicação de metadados Vetadata . . . . . . . . . . . . . . . . . . . . . 307C.59 Perfil de Aplicação de metadados MELT . . . . . . . . . . . . . . . . . . . . . . . 308C.60 Perfil de Aplicação de metadados ReGov LOM . . . . . . . . . . . . . . . . . . . 309C.61 Perfil de Aplicação de metadados Normetic . . . . . . . . . . . . . . . . . . . . . 309C.62 Perfil de Aplicação de metadados Organic Edu.net . . . . . . . . . . . . . . . . . 310C.63 Perfil de Aplicação de metadados CG LOM . . . . . . . . . . . . . . . . . . . . . 310C.64 Perfil de Aplicação de metadados RLLOMAP . . . . . . . . . . . . . . . . . . . . 311C.65 Perfil de Aplicação de metadados CerOrganic AP . . . . . . . . . . . . . . . . . . 311C.66 Perfil de Aplicação de metadados LORELOM . . . . . . . . . . . . . . . . . . . . 312C.67 Perfil de Aplicação de metadados scoLOMFR . . . . . . . . . . . . . . . . . . . . 312C.68 Perfil de Aplicação de metadados LRE AP . . . . . . . . . . . . . . . . . . . . . . 313C.69 Perfil de Aplicação de metadados BEN . . . . . . . . . . . . . . . . . . . . . . . . 313C.70 Lista dos Perfis de Aplicação no domínio Património Cultural . . . . . . . . . . . 314C.71 Perfil de Aplicação de metadados MAG . . . . . . . . . . . . . . . . . . . . . . . 314C.72 Perfil de Aplicação de metadados QuinkMap . . . . . . . . . . . . . . . . . . . . 315C.73 Perfil de Aplicação de metadados Folklore Description AP . . . . . . . . . . . . . 315C.74 Perfil de Aplicação de metadados PICO . . . . . . . . . . . . . . . . . . . . . . . 316C.75 Perfil de Aplicação de metadados EMAP . . . . . . . . . . . . . . . . . . . . . . . 316C.76 Perfil de Aplicação de metadados ESE . . . . . . . . . . . . . . . . . . . . . . . . 317C.77 Perfil de Aplicação de metadados EDM . . . . . . . . . . . . . . . . . . . . . . . 317C.78 Lista dos Perfil de Aplicação de metadados no domínio dos Outros . . . . . . . . 318C.79 Perfil de Aplicação de metadados IOAP . . . . . . . . . . . . . . . . . . . . . . . 318C.80 Perfil de Aplicação de metadados OAI-ORE . . . . . . . . . . . . . . . . . . . . . 319C.81 Perfil de Aplicação de metadados CRAP . . . . . . . . . . . . . . . . . . . . . . . 319C.82 Perfil de Aplicação de metadados IAP . . . . . . . . . . . . . . . . . . . . . . . . 320C.83 Perfil de Aplicação de metadados DC2AP . . . . . . . . . . . . . . . . . . . . . . 320C.84 Perfis de Aplicação seleccionados mas não utilizados no estudo . . . . . . . . . . 322C.85 Classificação dos Esquemas de Metadados . . . . . . . . . . . . . . . . . . . . . . 323C.86 Lista dos Esquemas de Metadados por domínio . . . . . . . . . . . . . . . . . . . 324C.87 Esquemas de codificação de sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . 330C.88 Esquemas de codificação de vocabulário . . . . . . . . . . . . . . . . . . . . . . . 332

Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica xv

Lista de Tabelas

xvi Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Lista de Figuras

2.1 A arquitectura da Web Semântica (modelo de 2007) segundo a W3C. . . . . . . . 122.2 Modelo do DCAP segundo o Enquadramento de Singapura Baker et al. (2008). . 182.3 Níveis de interoperabilidade segundo a Dublin Core Metadata Initiative - Nilsson

et al. (2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Framework definida por Gregor and Hevner (2013) apresentando a contribuiçãopara o conhecimento de um projecto de DSR. . . . . . . . . . . . . . . . . . . . . 38

3.2 Os três ciclos definidos por Hevner (2007) . . . . . . . . . . . . . . . . . . . . . . 403.3 Esquema da aplicação específica do enquadramento metodológico. . . . . . . . . 423.4 As três bases de conhecimento para o desenvolvimento do artefacto. . . . . . . . 44

4.1 Esquema da aplicação específica do enquadramento metodológico - Espaço Envi-ronment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Esboço proposto por um dos participantes . . . . . . . . . . . . . . . . . . . . . . 564.3 Esquema da aplicação específica do enquadramento metodológico - Espaço Kno-

wledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4 A arquitectura do Rational Unified Process segundo Kruchten (2004). . . . . . . 684.5 Esquema da aplicação específica do enquadramento metodológico - Espaço Design

Science Research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.6 As fases do Method for the Development of Dublin Core Application Profiles V0.1

e V0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.7 As fases do Method for the Development of Dublin Core Application Profiles V1.0. 754.8 Bases de conhecimento para a definição das fases e do ciclo de vida do Method for

the Development of Dublin Core Application Profiles. . . . . . . . . . . . . . . . 764.9 O ciclo de vida do Me4DCAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.10 As bases de conhecimento para a definição dos artefactos Glossário e Documentação

do DCAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.11 As bases de conhecimento para a definição dos deliverables Plano de Trabalho,

Documento Visão e Descrição Alto-nível dos Casos-de-Uso (V0.1) ou Expressãodos Requisitos Funcionais (V0.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.12 As bases de conhecimento utilizadas para a definição dos deliverables Plano deTrabalho, Documento Visão e Estado da Arte contexto de aplicação e Requisitosde alto nível - V1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.13 Detalhe da interligação das actividades do Method for the Development of DublinCore Application Profiles V1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.14 As bases de conhecimento para a definição do artefacto Modelo de Casos-de-Uso 834.15 As bases de conhecimento utilizadas para a definição do deliverable Requisitos

Funcionais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.16 As bases de conhecimento para a definição do artefacto Environmental Scan. . . 84

xvii

Lista de Figuras

4.17 As bases de conhecimento para a definição do deliverable Modelo de Domínio. . . 854.18 As bases de conhecimento utilizadas para a definição do artefacto Pré-Description

Set Profile V0.1 e V0.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.19 As bases de conhecimento utilizadas para a definição do artefacto Pré-Description

Set Profile V1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.20 As bases de conhecimento utilizadas para a definição do artefacto Validação em

Laboratório. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.21 O artefacto Critérios de Adequação definido na validação Focus Group. . . . . . 874.22 O Rational Unified Process como base de conhecimento utilizada para a definição

do artefacto Validação em Produção. . . . . . . . . . . . . . . . . . . . . . . . . . 884.23 As bases de conhecimento utilizadas para a definição dos deliverables Guias de

Utilização e Guias de Sintaxe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.24 Base de conhecimento utilizada para a definição de Method for the Development

of Dubin Core Application Profiles V1.0 . . . . . . . . . . . . . . . . . . . . . . . 894.25 Percurso do desenvolvimento do Method for the Development of Dublin Core

Application Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.1 As etapas de singapura e os respectivos deliverables . . . . . . . . . . . . . . . . . 1005.2 A interligação das actividades do Method for the Development of Dublin Core

Application Profiles V1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.3 As fases do Method for the Development of Dublin Core Application Profiles V1.0.1055.4 Diagrama de contexto da Etapa de Singapura: Desenvolver os Requisitos Funcionais.1075.5 Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Modelo

de Casos-de-Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.6 Diagrama de contexto da Etapa de Singapura: Desenvolver o Modelo de Domínio 1105.7 Diagrama de contexto da Etapa de Singapura: Desenvolver o Description Set Profile1125.8 Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Pré-Des-

cription Set Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.9 Proposta de modelo da Matriz de Restrições (baseada em Baker and Coyle (2009)).1135.10 Diagrama de actividades - nível 1 da actividade composta: Desenvolver a Validação

em Laboratório. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.11 Proposta de modelo de documento de Teste em Laboratório . . . . . . . . . . . . 1175.12 Diagrama de contexto da Etapa de Singapura: Desenvolver os Guias de Utilização 1185.13 Diagrama de contexto da Etapa de Singapura: Desenvolver os Guias de Sintaxe . 119

6.1 Diagrama de contexto da Etapa de Singapura: Desenvolver os Requisitos Funcionais1246.2 Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Modelo

de Casos-de-Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.3 Redes locais e cadeias produtivas de Economia Social e Solidária. . . . . . . . . 1346.4 Exemplo de cadeia produtiva de Economia Social e Solidária - caso Justa Trama. 1356.5 Redes regionais, nacionais, internacionais e sectoriais de Economia Social e Solidária.1366.6 Interfaces de interoperabilidade entre os Sistemas de Informação Web da Economia

Social e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506.7 Diagrama UML de Casos-de-Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.8 Diagrama de contexto da Etapa de Singapura: Desenvolver o Modelo de Domínio 1536.9 Modelo de Domínio do Dublin Core Application Profile - Economia Social e Solidária1686.10 Diagrama de contexto da Etapa de Singapura: Desenvolver o Description Set Profile.1696.11 Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Pré-Des-

cription Set Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

xviii Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Lista de Figuras

6.12 Diagrama de actividades - nível 1 da actividade composta: Realizar a Validaçãoem Laboratório. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.13 Entidade SSE-Initiative - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

6.14 Entidade Network - Modelo de Dados do Dublin Core Application Profile - Econo-mia Social e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

6.15 Entidade Product-Service - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

6.16 Entidade Cost - Modelo de Dados do Dublin Core Application Profile - EconomiaSocial e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

6.17 Entidade Sale Option - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

6.18 Entidade Location of Sale - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

6.19 A Entidade Cost Composition decomposta em Labour, Input e Other Costs -Modelo de Dados do Dublin Core Application Profile - Economia Social e Solidária.175

6.20 Matriz de restrições do Dublin Core Application Profile - Economia Social eSolidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.21 Diagrama UML de classes do Dublin Core Application Profile - Economia Social eSolidária. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

6.22 Tabela resumo do novo vocabulário criado: ESSGlobal V1.0. . . . . . . . . . . . 1876.23 Grafo com todas as classes do vocabulário ESSGlobal e respectivas relações

(owl:ObjectProperty) entre classes. . . . . . . . . . . . . . . . . . . . . . . . . . . 1976.24 Grafo com as propriedades (owl:ObjectProperty) “hasProductOrService”, “has-

Cost” “hasSaleOption” e “isComposedBy” do vocabulário ESSGlobal. . . . . . . 1996.25 Grafo com as propriedades (owl:ObjectProperty) “isAvailableAt”, “hasInputCost”

“hasLabourCost” e “hasOtherCosts” do vocabulário ESSGlobal. . . . . . . . . . . 1996.26 Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal

das classes SSEInitiative e Network. . . . . . . . . . . . . . . . . . . . . . . . . . 2116.27 Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal

das classes ProductOrService, Input e OtherCosts. . . . . . . . . . . . . . . . . . . 2116.28 Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal

das classes SaleOption e Labour. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116.29 Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal da

classe LocationOfSale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

C.1 A linha do tempo dos Perfis de Aplicação de metadados estudados . . . . . . . . 273

E.1 Base de conhecimento utilizada para a definição de Method for the Developmentof Dubin Core Application Profiles V0.1 . . . . . . . . . . . . . . . . . . . . . . . 353

E.2 Base de conhecimento utilizada para a definição de Method for the Developmentof Dubin Core Application Profiles V0.2 . . . . . . . . . . . . . . . . . . . . . . . 355

Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica xix

Lista de Figuras

xx Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Lista de acrónimos

ADWIS Analysis and Design of Web Based Information Systems

DCAM Dublin Core Abstract Model

DCAP Dublin Core Application Profile

DCAP-ESS Dublin Core Application Profile para os Sistemas de Informação Web dacomunidade mundial de Economia Social e Solidária

DCAP-SSE Dublin Core Application Profile for the Social and Solidarity Economy

DCMES Dublin Core Metadata Element Set - Versão 1.1

DCMI Dublin Core Metadata Initiative

DSR Design Science Research

DSP Description Set Profile

DCTERMS DCMI Metadata Terms

EOS Evolutionary Object-oriented Software development

ER Diagrama Entidade-Relacionamento

ESS Economia Social e Solidária

FG Focus Group

IA Investigação-Acção

Me4DCAP Método para o desenvolvimento de Dublin Core Application Profiles

OMT Object Modelling Technique

ORM Object Role Modeling

OWL Web Ontology Language

PA Perfil de Aplicação de metadados

RDF Resource Description Framework

RIPESS Réseaux Intercontinental de Promotion de l’Économie Social Solidaire

xxi

Lista de acrónimos

RMDM Relationship Management Data Model

RMM Relationship Management Methodology

RUP Rational Unified Process

SSE Social and Solidarity Economy

SES Syntax Enconding Schemes

SIW Sistemas de Informação Web

SKOS Simple Knowledge Organization System

SPARQL Protocol and RDF Query Language

UdD Universo de Descoberta

UML Unified Model Language

VAB Valor Acrescentado Bruto

VES Vocabulary Enconding Schemes

W3C World Wide Web Consortium

XML Extensible Markup Language

WSDM Web Site Design Model

WS Web Semântica

xxii Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Opções de normalização e de grafia

Para a normalização do trabalho utilizamos as normas para formatação de teses da Universidadedo Minho - Despacho RT-32 de 2005.

Utilizamos as normas da American Psychological Association (APA) para elaboração das citaçõese das referências bibliográficas.

Por opção da autora, a ortografia da tese ora apresentada não segue as regras do AcordoOrtográfico de 1990: não existem fontes credíveis sobre a utilização das regras ortográficas nelecontidas, e existem opções díspares sobre a sua aplicação nas diversas fontes que declaram adoptaras referidas regras.

Quanto à grafia das palavras:• relativamente à descrição do Método para o desenvolvimento de Dublin Core ApplicationProfiles (Me4DCAP), os nomes referentes a (i) artefactos ou deliverables; (ii) actividades;(iii) fases de trabalho; (iv) perfis de utilizador da equipe de trabalho são escritos emmaiúsculas;

• escrevemos em itálico todos os termos em outros idiomas diferentes do português. Exceptono caso de se tratar de um acrónimo por extenso quando da primeira vez citado ounos documentos produzidos no âmbito do desenvolvimento do Dublin Core ApplicationProfile para os Sistemas de Informação Web da comunidade mundial de Economia Social eSolidária (DCAP-ESS);

• escrevemos em itálico trascrições de entrevistas ou reuniões;• os termos que foram mantidos em outros idiomas não foram traduzidos porque entendemos

que estes são comumente utilizados no seu original, ou porque a tradução não seria favorávelao entendimento do texto;

• foram mantidos em inglês todos os termos do Resource Description Framework (RDF) e doDescription Set Profile (DSP) ou de qualquer outro termo pertencente a um vocabuláriosemântico;

• utilizamos aspas para destacar palavras ou expressões do texto (excepto nos casos em queestas estejam noutro idioma), ou para citações. No último caso a citação é seguida dareferência bibliográfica.

xxiii

Opções de normalização e grafia

xxiv Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

Capítulo 1

Introdução

SEEDAll life starts from seed. If we want to follow life, we need only to follow thecourse of seed to seed.

Deng Ming-Dao

Este capítulo faz a contextualização da Tese, identifica o problema a resolver e a oportunidadeencontrada. Descreve ainda, sucintamente, a motivação e pertinência do trabalho, tanto na áreacientífica como na situação experimental. Posteriormente, define a natureza e âmbito do estudorealizado. Por último, descreve a estrutura desta Tese, referindo de forma breve os capítulos quea compõem.

1.1 Contextualização

À capacidade de diferentes tipos de computadores, redes, sistemas operativos e aplicaçõestrabalharem em conjunto com eficácia, sem comunicação prévia, e de forma a trocarem informaçãoútil e com significado dá-se o nome de “interoperabilidade” DCMI (2011). Os sistemas não podeminteroperar entre si naturalmente, isso só irá acontecer se forem desenhados especificamente paraesse fim Lister (2008). O nosso trabalho situa-se no contexto da Web Semântica (WS), ondeexiste uma forma particular de interoperabilidade, a “interoperabilidade semântica”. A utilizaçãode metadados e de ontologias, e de tecnologias da WS tais como a linguagem padrão ResourceDescription Framework (RDF), permite que o verdadeiro sentido dos dados partilhados sejaentendido pelas máquinas sem que haja intervenção humana Nagamori and Sugimoto (2006);Shadbolt et al. (2006); Scholl (2005).

A Dublin Core Metadata Initiative (DCMI) define “uma base para o desenvolvimento delinguagens independentes de especificação de sintaxe e de restrições” Powell et al. (2007), oDublin Core Abstract Model (DCAM). Ele apresenta os componentes e os constructos utilizadosnos metadados da DCMI. Um destes constructos é o Dublin Core Application Profile (DCAP) -“um constructo genérico para desenhar registos de metadados” Baker and Coyle (2009). Possuirum DCAP como referência e ligação para descrever os recursos de uma comunidade é, segundo

1

1. Introdução

a DCMI, essencial para que essa comunidade atinja o mais elevado nível de interoperabilidadesemântica. Por essa razão o DCAP é um constructo muito importante, e por isso, ele é o centrodo nosso trabalho de investigação.

1.2 Problema e oportunidade

Um DCAP é um constructo enquadrado pela recomendação Singapore Framework for DublinCore Application Profiles Baker et al. (2008). E caso uma comunidade possua um DCAP e outilize como referência e ligação para descrever os seus recursos, esta tem a possibilidade deobter um alto nível de interoperabilidade semântica, nomeadamente o quarto nível no modelode camadas definido pela DCMI Nilsson et al. (2009). A forma como um DCAP é definido estábem patente no documento já referido Singapore Framework for Dublin Core Application ProfilesBaker et al. (2008). Contudo, os trabalhos efectuados de revisão de literatura, e outros estudoscomplementares, revelaram que não existe um método para o desenvolvimento de um DCAP,ferramenta importante no desenvolvimento de soluções de interoperabilidade ao nível da troca dedados da Web. Este é o nosso “problema”:

A comunidade de metadados mundial não possui um método para o desenvolvimentode um DCAP. É necessário desenvolver um.

O objectivo do nosso trabalho é a resolução deste problema.Além disso, após estudos por nós realizados concluimos que não há nenhum DCAP na

comunidade mundial de metadados que sirva as necessidades da comunidade de Economia Sociale Solidária (ESS). Assim, identificamos a necessidade de desenvolver um DCAP para estacomunidade em particular; trata-se de uma oportunidade de utilizarmos este desenvolvimentocomo situação experimental de trabalho. Esta é a nossa “oportunidade”:

A ESS não possui um DCAP que sirva as necessidades dos seus Sistemas de InformaçãoWeb (SIW), é por isso necessário desenvolver um Dublin Core Application Profilepara os Sistemas de Informação Web da comunidade mundial de Economia Sociale Solidária (DCAP-ESS). Este trabalho de desenvolvimento será utilizado comosituação experimental do nosso trabalho de investigação.

Este trabalho utilizou a metodologia de investigação Design Science Research (DSR), noenquadramento definido por Hevner (2007).

Sendo o constructo DCAP um modelo de dados, uma vez que ele é definido a partir de umconjunto de termos de metadados que descrevem o modelo de domínio previamente definido, ométodo para o desenvolvimento de DCAP foi concebido tendo como ponto de partida os métodosou processos da engenharia de software que trabalham nas suas primeiras fases do ciclo de vida,a modelação de dados. Esse ponto de partida foi adaptado às necessidades específicas do DCAP,recorrendo a entrevistas realizadas a pessoas que desenvolveram DCAP, recorrendo a práticasde desenvolvimendo de DCAP registadas na literatura da comunidade de metadados, e aindautilizando uma situação real, que se concretizou no desenvolvimento do DCAP-ESS, para ir

2 Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica

1. Introdução

testando o método em desenvolvimento. Esta situação real permitiu a realização de um processoiterativo, em que a informação resultante da aplicação do método em construção alimentava essaconstrução, e a construção do método ia sendo testada na criação do DCAP-ESS.

1.3 Motivação e pertinência

1.3.1 Na área científica

No trabalho de revisão de literatura desenvolvido e em estudos complementares verificou-seque não existe, tanto quanto foi possível apurar, nenhum método para o desenvolvimento deum DCAP (c.f secção 2.3). De facto, uma análise de conteúdo realizada a artigos científicos,manuais, relatórios e sítios Web, todos eles com informação sobre o desenvolvimento de umPerfil de Aplicação de metadados (PA) ou de um DCAP, revelou a não existência de formasde modelar e de trabalhar Wijers (1991) estes constructos. A ausência deste método é umalacuna na comunidade de metadados, e é um problema dada a importância da Web e a grandeactividade dos seus agentes. As organizações necessitam de modelos de dados que apoiem assuas necessidades de interoperabilidade, e a concepção desses modelos necessita, naturalmente,de métodos.

1.3.2 Na situação experimental

A situação experimental do nosso trabalho acontece no seio da ESS. Não foi encontrado, tantoquanto conseguimos apurar, nenhum PA ou DCAP que sirva os interesses desta comunidade.

A Technological Accceptance Model, uma teoria sobre aceitação de tecnologia, revela que aatitude perante uma ferramenta tecnológica é um factor que influencia directamente o sucessoda sua implementação Davis (1985). Por essa razão, achamos que a oportunidade de trabalharem conjunto com a comunidade de ESS no sentido de desenvolver um DCAP-ESS seria algoexcepcional. Deste modo, trabalhamos com um consórcio da Réseaux Intercontinental dePromotion de l’Économie Social Solidaire (RIPESS), uma rede que enquadra várias sensibilidadesexistentes no mundo da ESS. Esperamos que este facto contribua para a aceitação do DCAP-ESSpela comunidade a que se destina, já que o DCAP-ESS foi desenvolvido com pessoas oriundas darede que congrega diferentes organizações representativas de diferentes interesses e perspectivasda ESS. O desenvolvimento do DCAP-ESS foi a “situação experimental“ Hevner (2007) doDesign Cycle do enquadramento DSR de Hevner (2007).

A comunidade ESS tem vindo a ser muito estudada por áreas científicas como as de sociologiae de economia, mas não pelas áreas ligadas à tecnologia. Foi claro do estudo que fizemossobre os SIW da ESS que os elementos da RIPESS viram o trabalho de desenvolvimento de umenquadramento para a interoperabilidade dos seus SIW como uma tarefa que não estava ao seualcance, necessitando de uma ajuda externa. Constatamos que a ligação à Academia é vistacomo motivadora e dignificadora do trabalho da comunidade ESS; este facto coloca-os no mapamundial no que diz respeito à investigação científica, ganhando por isso credibilidade perante aspossíveis entidades financiadoras.

Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica 3

1. Introdução

1.4 Natureza e âmbito do estudo

Este trabalho de investigação é um primeiro contributo para a concepção de um método para odesenvolvimento de DCAP. Para isso, partimos do conhecimento já sedimentado sobre métodosde desenvolvimento de software, centrando-nos nas fases iniciais destes que vão até à modelaçãode dados. Analisamos estes métodos e seleccionamos um dos métodos mais utilizados, senão omais utilizado, da Engenharia de Software, que enriquecemos com modelos teóricos e práticasda comunidade de metadados, de forma a adequá-lo o mais possível ao contexto aberto da WS.Este contexto é aberto porque não está confinado a uma ou várias organizações, onde se conheceo tipo de utilizadores da aplicação e o contexto particular da sua utilização. Além disso, asaplicações da WS estão expostas a situações com características culturais, linguísticas, sociaise organizacionais muito distintas. Partindo do método adequado, oriundo da engenharia desoftware, o nosso contributo foi a nível das alterações que realizámos tendo em conta a realidadeda WS em particular.

Este trabalho é um estudo de investigação que possui duas partes. Uma que trouxe umcontributo para modelos teóricos, relativamente às questões metodológicas, e outra de investigaçãoaplicada que culminou com o desenvolvimento do DCAP-ESS. O ambiente da ESS é o contextoda situação real do trabalho de investigação, cumprindo os requisitos de complexidade (contextoaberto, multi-cultural, multi-social, multi-linguístico, etc.) descritos anteriormente.

Este estudo foi apenas efectuado no âmbito da comunidade ESS que, embora sendo mundial,multi-cultural, com diferentes idiomas e multi-aplicacional, pode não englobar em si mesma todasas características passíveis de serem encontradas noutras comunidades com diferentes graus deheterogeneidade uma vez que pode haver situações mais complexas do que a utilizada. Estasituação da comunidade ESS cumpre os critérios de abertura e de heterogeneidade estabelecidos,mas provavelmente haverá situações mais complexas das quais o Método para o desenvolvimentode Dublin Core Application Profiles (Me4DCAP) por nós desenvolvido ao ser aí testado possabeneficiar. Não se pretende, por conseguinte, propôr uma solução universal, mas antes um pontode partida para o estudo e desenvolvimento desta problemática no seio de diferentes comunidadesde metadados.

1.5 Organização da Tese

Esta Tese está organizada em sete capítulos. No capítulo 2 apresentamos na primeira parte areflexão dos conceitos de WS, de metadados e de interoperabilidade semântica no contexto da WS.Apresentamos ainda a definição do constructo PA, objecto central da Tese, e a sua importânciapara o desenvolvimento de aplicações na Web que sejam semanticamente interoperáveis; nasegunda parte deste capítulo apresentamos o estado da arte dos métodos para o desenvolvimento deum PA, terminando com as conclusões que justificam a existência do nosso trabalho de investigação.No capítulo seguinte, o capítulo 3, apresentamos a metodologia de investigação utilizada nodesenvolvimento do trabalho. Iniciamos o capítulo com uma pequena resenha sobre metodologiasde investigação, seguimos com uma exposição sobre a metodologia de investigação utilizada no


1. Introdução

projecto de investigação, a DSR; de seguida apresentamos o enquadramento particular da DSRpor nós utilizado. Terminamos o capítulo com um resumo da forma como este enquadramento emparticular foi aplicado no nosso trabalho. O capítulo 4 apresenta de uma forma pormenorizada,o trabalho por nós desenvolvido nos três Espaços de trabalho do enquadramento metodológicoparticular que utilizamos. No capítulo 5 apresentamos o resultado deste projecto de doutoramento:o método para o desenvolvimento de DCAP - Versão 1.0. No capítulo 6 descrevemos a situaçãoexperimental do caso de investigação, o trabalho desenvolvido com um grupo da comunidade deESS no sentido de desenvolver o DCAP-ESS Versão 1.0. O último capítulo desta Tese é compostopelas conclusões, pelas principais contribuições e limitações, e pelas perspectivas futuras dotrabalho.


1. Introdução


Capítulo 2

Fundamentos teóricos e estado daarte

STANCEWithout a strong stance, all other movements are impossible.

Deng Ming-Dao

Este capítulo inicia-se com a apresentação da metodologia utilizada no trabalho: aí são expostas(i) as estratégias de pesquisa tanto para os fundamentos teóricos como para a elaboração doestado da arte dos métodos de desenvolvimento de um Perfil de Aplicação de metadados (PA); e(ii) a forma como foi realizada a análise de conteúdo necessária à elaboração do estado da arte dosmétodos de desenvolvimento de um PA. De seguida são apresentados os fundamentos teóricosdo nosso trabalho de investigação; aí fazemos uma contextualização, posicionando-nos na WebSemântica (WS) e no contexto particular do constructo Dublin Core Application Profile (DCAP).Explicamos ainda a importância do DCAP para a construção de ambientes Web semanticamenteinteroperáveis. De seguida apresentamos o Estado da Arte dos métodos de desenvolvimentode um PA. O capítulo termina com a conclusão de que não existe nenhum método para odesenvolvimento de um PA, justificando assim a razão deste trabalho de investigação.

2.1 Metodologia de trabalho

O nosso trabalho de revisão de literatura inclui uma parte que trata os fundamentos teóricos dotrabalho, e uma segunda parte que resulta no estado da arte dos métodos para o desenvolvimentode um PA. Esta secção apresenta a metodologia usada: (i) na estratégia de pesquisa paraa reflexão efectuada sobre os fundamentos teóricos e para o estado da arte dos métodos dedesenvolvimento de um PA; (ii) no trabalho de análise de conteúdo para a realização do Estadoda Arte dos métodos de desenvolvimento de um PA.

7

2. Fundamentos teóricos e estado da arte

2.1.1 Estratégias de pesquisa

Realizamos pesquisas bibliográficas com pesquisas gerais e depois refinadas nas bases de dadosonline, e ainda consultamos os sítios Web relevantes, dependendo dos conceitos a estudar. Asbases de dados utilizadas foram o Google Scholar1, o ISI Web of Knowledge2, o SCI ETDNetworked Digital Library of Thesis and Dissertations3, o Scopus4 e o Oaister5.

As pesquisas realizadas nas bases de dados online utilizaram termos-chave que mais à frenteserão especificados, eles dependem da especificidade de cada pesquisa.

As pesquisas foram realizadas nos campos “título do artigo”, “assunto” e “corpo do artigo”,com a excepção de quando se pesquisou por um autor específico, nesse caso, a pesquisa foirealizada no campo “autor”. Incialmente os artigos foram seleccionados seguindo o critério de“relevância do título”, “número de citações” e de qualidade da “revista científica” (com um factorde impacto JCR/SJR mais elevado). Numa fase posterior, foram pesquisados artigos a partir donome dos autores relevantes identificados até à data.

Na segunda fase das pesquisas, foram analisadas as referências dos artigos retidos na fase 1,seleccionando novos artigos pela relevância do título e mais tarde pela relevância do sumário. Oprocesso foi iterativo em relação aos novos artigos encontrados, terminando quando os artigos sereferenciavam mutuamente.

Na terceira fase das pesquisas foram recuperados artigos que citavam os artigos basilares. Osnovos artigos foram seleccionados segundo o mesmo critério referido na fase 2 da pesquisa.

2.1.1.1 Fundamentos teóricos

No sentido de realizar uma revisão de literatura sobre WS, PA e DCAP, interoperabilidadee interoperabilidade semântica, utilizamos, nas nossas pesquisas nas bases de dados online,os seguintes termos-chave : “Metadados”; “Esquemas de metadados”; “Perfil de Aplicação”e “Metadados”; “Web Semântica”; “Interoperabilidade”; “interoperabilidade” e “Metadados”;“Interoperabilidade semântica”; “Interoperabilidade semântica” e “Metadados”.

As pesquisas foram realizadas em Português, Espanhol e Inglês.Além disso, consultamos os sítios Web da World Wide Web Consortium (W3C)6 e o sítio

“Semantic Web”7 para o conceito deWS e o sítio Web da Dublin Core Metadata Initiative (DCMI)8

para os conceitos de Dublin Core Abstract Model (DCAM) e DCAP.

2.1.1.2 Estado da arte dos métodos para o desenvolvimento de um PA

O nosso trabalho de pesquisa dividiu-se em duas partes:

1http://scholar.google.com - acedido em Junho de 20112http://www.isiWebofknowledge.com - acedido em Junho 20113http://www.ndltd.org/serviceproviders/scirus-etd-search - acedido em Junho 20114http://www.scopus.com - acedido em Junho 20115http://oaister.worldcat.org - acedido em Junho 20116http://www.w3.org/standards/semanticweb/ - acedido em Junho 2011. Verificado em 3 de Março 2014.7http://semanticweb.org - acedido em Junho de 2011. Verificado a 3 de Março 2014.8http://dublincore.org - acedido em Junho 2011. Verificado em 3 de Março 2014.


http://scholar.google.com

http://www.isiWebofknowledge.com

http://www.ndltd.org/serviceproviders/scirus-etd-search

http://www.scopus.com

http://oaister.worldcat.org

http://www.w3.org/standards/semanticweb/

http://semanticweb.org

http://dublincore.org


• Parte 1análise dos PA apresentados na secção 6.3.1;

• Parte 2identificação e análise dos métodos existentes utilizados para o desenvolvimento de PA.

Relativamente à Parte 1, a pesquisa bibliográfica é apresentada na secção 6.3.1.2.1.Relativamente à Parte 2, os termos-chave utilizados nas base de dados online foram: “Meto-

dologias” e “Perfil de Aplicação”; “Métodos” e “Perfil de Aplicação”; “Metodologias” e “DublinCore Application Profile”; “Métodos” e “Dublin Core Application Profile“; ”Metadados“ e”Metodologias“; ”Metadados“ e ”Métodos“.

As pesquisas foram realizadas em Inglês.Além desta pesquisa bibligráfica ainda efectuamos outras diligências para obter mais informa-

ção:• realizámos pesquisas no motor de busca Google9 com os mesmos termos usados na pesquisabibliográfica;

• pedido de informações sobre o desenvolvimento de PA na mailing list “General“ da DCMI10;• pedido de informações sobre o desenvolvimento de PA na mailing list ”Architecture” daDCMI11.

2.1.2 Análise de conteúdo - estado da arte dos métodos para o desenvolvi-mento de um Perfil de Aplicação de metadados

Para efectuar o estado da arte dos métodos para o desenvolvimento de um PA foi ainda necessáriorealizar uma análise de conteúdo a alguns dos documentos seleccionados nas pesquisas. Istofoi necessário por haver a necessidade de identificar “formas de desenvolver” PA implicitas nosdocumentos. O objecto principal dos autores dos documentos era a descrição de PA ou análisecomparativa de PA, não sendo realmente nestes documentos explicito a forma como os PA foramdesenvolvidos.

A análise de conteúdo de cada item (texto ou página Web) que obtivemos das pesquisasseguiu a seguinte metodologia:

1. Todos os items a ser analisados foram impressos e numerados;2. Criou-se um documento de texto: o documento matriz;3. Uma nova linha foi criada no documento matriz, com um número como referência ao artigo

a ser analisado (número definido em 1);4. Sempre que houvesse informação importante a reter ela era copiada no documento matriz

com uma referência ao número de página de onde tinha sido retirada (caso fosse um artigo,caso fosse uma página Web nenhum número de página era retido). Esta página terminavasempre que não houvesse mais informação importante no item a ser analisado;

5. O processo retorna ao ponto 3 até não haver mais items a serem analisados.Organizamos os items em 3 categorias distintas:9http://www.google.com

[email protected]@jiscmail.ac.uk



• artigos científicos, documentos técnicos ou manuais que referem explicitamente métodospara o desenvolvimento de PA ou métodos que tenham a ver com aplicações de metadadose melhores práticas. Vamos categorizá-los como “Manuais”;

• um conjunto de artigos científicos que sistematizam informação relacionada com áreasespecíficas ou áreas horizontais. Estamos a referir-nos a artigos que reportem estadosda arte de PA num domínio específico, ou que analisam uma determinada característicano desenvolvimento de PA em todos os domínios. Vamos categorizá-los como “Artigosmetodológicos”;

• um conjunto de artigos científicos que reportam o desenvolvimento de PA. Estes artigospossuem secções que referem “formas de fazer”, “formas processuais de fazer”, “receitas”,mais ou menos abrangentes. Vamos categorizá-los como “Artigos perfis”.

Em cada item com informação decidimos definir objectivamente dois pontos:• os passos que o item define para uma determinada metodologia/técnica/método: chamamos

a isso “passos”. “Sim” se há passos definidos; “Não” caso não haja;• como esses passos têm de ser executados: chamamos a isso “como”;• quando o item define um “como”, queremos medir qual a parte do PA que está coberta

por esse “como”. Definimos uma escala de faixa de cobertura do PA no que diz respeito ao“como” - chamamos-lhe “cobertura”. Essa “cobertura” pode ter três valores:

1. Parcialmente coberto - 1;2. Moderadamente coberto - 2;3. Totalmente coberto - 3.

Quando não há definição de “como”, a cobertura é definida com um “n/d”.

2.2 Fundamentos teóricos

Esta secção apresenta os fundamentos teóricos do nosso trabalho de investigação. Iniciamosa secção introduzindo o conceito de WS, seguido da definição dos conceitos de metadados eesquemas de metadados e de interoperabilidade. De seguida apresentamos ainda os conceitos dePA e DCAP. Terminamos esta secção explicando a relação existente entre o constructo DCAP eo conceito de interoperabilidade semântica.

2.2.1 Web semântica

Segundo a visão de 2001 de Berners-Lee et al. a WS não seria uma Web separada da Web queutilizamos todos os dias, mas antes uma extensão desta, onde a informação seria fornecida comum significado bem definido, permitindo aos computadores e às pessoas trabalhar em cooperação.Com quatorze anos volvidos, essa visão concretizou-se numa ”Web de dados“ W3C (2010)que permite a partilha de conteúdos para além das fronteiras das aplicações e dos sítios WebSemanticweb.org (2012); uma Web de dados ligados, em contraste com a “Web de documentos”.

A concretização da visão de Berners-Lee et al. (2001) ocorreu através da evolução tecnológica



e conceptual ocorrida em volta do paradigma da WS. A tecnologia Resource DescriptionFramework (RDF)12, 13, “um modelo padrão para o intercâmbio de dados na Web” W3C (2010),fornece a base para publicar e ligar os dados. Várias tecnologias, tais como o RDFa14 ou oGRDDL15, permitem embeber dados em documentos, ou expor esses dados em base de dadosSQL, ou ainda colocar os dados disponíveis em ficheiros RDF W3C (2010). Por outro lado, aWS possui uma linguagem de consulta, a Protocol and RDF Query Language (SPARQL)16, quepermite realizar consultas a dados disponíveis na Web de dados, possuindo assim as mesmaspossilidades que as suas congéneres do mundo das bases de dados relacionais, por exemplo. A WSpossui ainda vocabulários que “permitem definir os conceitos e as relações usadas para descreveruma área de conhecimento” W3C (2010) e ainda aplicar restrições sobre os dados. Atravésda utilização de linguagens como o Web Ontology Language (OWL)17 ou o Simple KnowledgeOrganization System (SKOS)18, ou ainda vocabulários RDF19 é possível criar ontologias ousistemas de organização do conhecimento. A WS permite ainda, através de ferramentas comoo Rule Interchange Format (RIF)20 ou o OWL, realizar inferências, isto é, descobrir novasrelações entre os dados realizando procedimentos automáticos, gerando novas relações baseadasem dados e nos vocabulários W3C (2010). Contudo, para criar de facto esta Web de dados nãoé suficiente realizar implementações utilizando as tecnologias disponíveis. É necessário aindaque a comunidade adira às normalizações existentes, que torne os seus dados disponíveis, e queestes possam ser utilizados e geridos pelas ferramentas da WS. Mais do que uma colecção dedatasets, a WS é então um conjunto de dados ligados, e por isso é também apelidada de LinkedData W3C (2010).

A arquitectura da WS é apresentada na Figura 2.1. Para o nosso trabalho, interessa-nosdefnir os conceitos de metadados e de esquemas de metadados. Os metadados estão presentesao nível da camada “Data interchange: RDF”; mas eles são definidos através de esquemas demetadados, estes estão presentes nas camadas "Taxonomies: RDFs“ e ”Ontologies: OWL“.

2.2.2 Metadados e esquemas de metadados

Os metadados são dados que descrevem dados, informação estruturada que descreve, explica elocaliza, ou torna fácil recuperar, usar ou gerir um recurso com informação Niso Press (2004).Um recurso é qualquer coisa que possa ser identificada. Como refere Rüle, Baker e Johnston“qualquer coisa de interesse pode ser descrito através de metadados, desde colecções de livros aligas de futebol e coisas que se queira vender (...)” (Rühle et al., 2011, p. 2).

12http://www.w3.org/TR/rdf-concepts - acedido em 2 de Novembro de 2012. Verificado a 3 de Março 201413Ou a sua extensão, RDF schema (RDFs) - http://www.w3.org/TR/rdf-schema/ - acedido em 4 Março 2014.14RDFa: http://www.w3.org/TR/2013/REC-rdfa-core-20130822/ - acedido em 3 de Março 201415Gleaning Resource Descriptions from Dialects of Languages: http://www.w3.org/TR/2007/

REC-grddl-20070911/ (GRDDL) - acedido em 3 de Março 2014.16Ver http://www.w3.org/TR/rdf-sparql-query/ - acedido em 6 de Setembro 2012. Verificado a 4 Março

2014.17http://www.w3.org/TR/owl2-primer/ - acedido em 4 Março 2014.18http://www.w3.org/TR/skos-reference/ - acedido a 4 Março 2014.19Ver por exemplo Data Cube Vocabulary (DCAT): http://www.w3.org/TR/vocab-data-cube/ - acedido a 4

Março 2014.20http://www.w3.org/TR/rif-prd/ - acedido a 4 março 2014.


http://www.w3.org/TR/rdf-concepts

http://www.w3.org/TR/rdf-schema/

http://www.w3.org/TR/2013/REC-rdfa-core-20130822/

http://www.w3.org/TR/2007/REC-grddl-20070911/

http://www.w3.org/TR/2007/REC-grddl-20070911/

http://www.w3.org/TR/rdf-sparql-query/

http://www.w3.org/TR/owl2-primer/

http://www.w3.org/TR/skos-reference/

http://www.w3.org/TR/vocab-data-cube/

http://www.w3.org/TR/rif-prd/


Figura 2.1: A arquitectura da Web Semântica (modelo de 2007) segundo a W3C.

Os metadados seguem regras bem definidas nos esquemas de metadados. Um esquema demetadados é um conjunto de elementos de metadados definido para um objectivo específico, numdeterminado contexto.

Um esquema de metadados é também chamado, por algumas sensibilidades, de “vocabulário”ou de “vocabulário RDF”. Na realidade isso acontece porque um vocabulário é um conjunto determos, e um termo pode ser um elemento, uma classe21, ou um esquema de codificação (desintaxe ou de vocabulário). Como pode ser visto mais adiante na secção 2.2.1, o conceito devocabulário evoluiu com a evolução da Web e com a evolução das suas linguagens ou esquemasde representação de conhecimento.

Cada elemento ou termo22 de um esquema de metadados tem um significado específico ebem definido dentro do esquema. Esta definição ou significado de cada elemento é chamadode “semântica do esquema” (Niso Press, 2004, pag. 2). Além disso, cada elemento tem regrasdefinidas para os valores que lhe estão associados. Estas regras podem ser concebidas para:

• a formulação do seu preenchimento - por exemplo, como definir o título principal, ou deque vocabulário vêm as palavras-chave;

• a representação do conteúdo - por exemplo, regras de capitalização, regras de numeração;• o preenchimento com valores definidos - por exemplo determinado elemento só poder serpreenchido com um termo de uma lista pré-definida Niso Press (2004).

Há várias iniciativas de esquemas de metadados em diferentes áreas, damos como exemploalgumas:

• DCMES23: uma iniciativa da DCMI com um domínio generalista;21Uma classe é uma espécie de categoria. Uma classe é um grupo de membros que têm atributos, comportamentos,

relacionamentos ou semântica em comum.22Também chamado de propriedade por algumas sensibilidades.23http://dublincore.org/documents/dces/ - acedido em 7 de Setembro de 2012.



• IEEE LOM24: uma iniciativa do IEEE no domínio dos recursos educativos;• AGLS25: uma inciativa do governo australiano, inicialmente para o domínio dos recursos

governamentais, mas que neste momento se auto-classifica como de domínio transversal;• METS26: uma iniciativa para descrição de objectos digitais no domínio das bibliotecas;• FOAF27: uma inciativa para descrição de recursos relacionados com redes sociais na Web;• PRISM28: uma inciativa para descrição de rescursos no domínio das publicações electrónicasde conteúdos para revistas, jornais, etc.

A iniciativa mais relevante, porque é a pioneira, e tem uma influência muito grande no mundoda descrição de metadados (ver secção 6.3.1), é a iniciativa da DCMI, o Dublin Core MetadataElement Set - Versão 1.1 (DCMES). A primeira versão 1.0 do DCMES foi criada em 1995, tinhaum conjunto de 15 elementos para uma descrição simples e genérica de recursos electrónicos. Em1998 a DCMI apresentou a segunda versão (Versão 1.1) que é a que permanece até aos dias dehoje.

A introdução de novos paradigmas na Web implicou necessariamente uma evolução nasdefinições dos esquemas de metadados da DCMI. Em Janeiro de 2008 a DCMI incluiu aspropriedades “domínio” e “contra-domínio” nas definições dos seus elementos29. Mas para nãoafectar as implementações já existentes, anteriores a esta nova formulação, desenvolvidas com oDCMES em RDF, não foi especificado o domínio e contra-domínio para estes 15 elementos doDCMES. O que aconteceu foi que se criaram 15 novos elementos com nomes idênticos aos doDCMES. Essas 15 novas propriedades foram definidas como sub-elementos (também referidoscomo refinamentos) dos correspondentes elementos do DCMES e foram-lhes atribuídos domínioe contra-domínio DCMI (2010). Além disso, a estes 15 novos elementos acrescentaram-se outros29 a que se chamaram os “termos qualificados” (qualified terms), e a este grupo de 44 termosdeu-se o nome de DCMI Metadata Terms (DCTERMS)30.

Esta introdução de domínio e contra-domínio, e ainda a definição de classe para os termos,trouxe a possibilidade de criar estruturas de conhecimento, relacionando conceitos e assimpossibilitar a emergência de um mundo onde é possível máquinas processarem semanticamenteinformação. Os vocabulários passam a definir os conceitos e as relações usados para descrever erepresentar uma área de conhecimento. Os vocabulários são usados para classificar os termosque podem ser utilizados para uma aplicação particular, caracterizam as relações possíveis, edefinem possíveis restrições sobre o uso destes termos. Na prática, os vocabulários podem sermuito complexos (com vários milhares de termos) ou muito simples (descrevendo um ou doisconceitos apenas) W3C (2012a). Na WS fala-se em ”ontologias“, mas na verdade não há umadistinção clara entre ”vocabulário“ e ”ontologia“. A tendência é de usar o termo ”ontologia“

24http://ltsc.ieee.org/wg12/ - acedido em 20 de Maio de 2012.25http://www.agls.gov.au/documents/aglsterms/ - acedido em 20 de Maio de 2012.26http://www.loc.gov/standards/mets/ - acedido em 29 de Novembro de 2011.27http://xmlns.com/foaf/spec/ -acedido em 29 de Novembro de 2011.28http://prismstandard.org/ - acedido em 29 de Novembro de 2011.29As propriedades “domínio” e “contra-domínio” existem para ligar um sujeito a um objecto. No caso do

domínio, quando se liga um sujeito a um objecto usando esta propriedade com este atributo associado, então osujeito será um tipo de coisa especificado pelo domínio. O contra-domínio funciona exactamente como o domínio,mas agora, a propriedade aplica-se ao objecto da declaração e não ao sujeito

30Ver http://purl.org/dc/terms/ - acedido em 10 de Setembro de 2012.


http://purl.org/dc/terms/


para colecções muito complexas. Os ”vocabulários” são os blocos de construção básicos paratécnicas de inferência na WS. O DCMES já não é um vocabulário neste sentido, uma vez quenão relaciona os diferentes elementos ao contrário do DCTERMS.

A DCMI modificou também na última década a sua forma de definir um recurso. Hoje “oâmbito de aplicação Dublin Core Metadata tem alargado de forma a abranger, em princípio,qualquer objecto que possa ser identificado, seja um objecto digital, um objecto no mundo real,ou até mesmo conceptual” (Rühle et al., 2011, p. 2). Assim, um recurso não necessita de estarconfinado ao mundo digital nem ao mundo físico, pode ser também algo que não existe em termosfísicos, algo intangível. Esta modificação teve como objectivo uma adaptação à evolução da Web,onde novos paradigmas surgiram entretanto. A WS é uma dessas evoluções.

Esta evolução da Web trouxe uma transformação na área dos metadados. A comunidadeDCMI organizou-se e concebeu novas ferramentas para que os agentes envolvidos na definição dasdescrições de metadados falassem uma linguagem comum. O DCAM surge com este objectivo.Ele é um modelo para as especificações de sintaxe da DCMI que apresenta os componentes e osconstructos usados nos metadados da DCMI. Define a natureza dos componentes utilizados edescreve a forma como eles se combinam para a criação de estruturas de informação Powell et al.(2007). O DCAM fornece um modelo de informação que é independente de qualquer sintaxe decodificação em particular. Ele é um modelo de informação que nos permite obter uma melhorcompreensão dos tipos de descrições que estamos a realizar e que nos ajuda no desenvolvimentode melhores mapeamentos Powell et al. (2007).

A primeira versão31 do DCAM foi apresentada em Março de 200532.Hoje, já em versão estável, a comunidade DCMI continua ainda aprofundando os conceitos

do DCAM de forma a que esta ferramenta continue a evoluir. Este debate faz-se na listaDCMI-architecture entre alguns especialistas presentes na lista33.

Todo este trabalho da comunidade DCMI tem a preocupação de se manter dentro de padrõesinternacionais e de juntar o maior número de pessoas respeitando esses padrões. No que dizrespeito ao DCMES - como referido anteriormente, o esquema de metadados mais influente nacomunidade mundial de metadados - ele foi endossado pelos seguintes padrões internacionaisDCMI (2010):

• IETF RFC 5013 de Agosto 2007;• ISO Standard 15836:2009 de Fevereiro 2009;• ANSI/NISO Standard Z39.85-2012 de Fevereiro de 2013.Outros esquemas foram também procurando trabalhar dentro da padronização, mais ou

menos internacional:31Ver http://dublincore.org/documents/2005/03/07/abstract-model/ - acedido em 21 de Junho de 2012.32Na DCMI há todo um workflow relativamente aos documentos técnicos. Quando uma versão é estável

toma a forma de uma recomendation - ver http://dublincore.org/documents/#recommendations. O DCAM nãofoi excepção e passou pelas várias formas até chegar à versão final de recomendation. Em Dezembro de 2004tomava a forma de Working Draft - ver http://dublincore.org/documents/2004/12/08/abstract-model/, eem Janeiro de 2005 a forma de Proposed Recomendation - ver http://dublincore.org/documents/2005/01/31/abstract-model/.

[email protected] - ver por exemplo o relatório da última reunião DCAM telecon(à data da escrita desta proposta) de 1 de Junho de 2012 em http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-201206xx


http://dublincore.org/documents/2005/03/07/abstract-model/




http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-201206xx

http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-201206xx


• Darwin Core: em 2009 foi endossado pela TDWG standard34;• GO-ITS 43: em 2005 foi endossado pelo Government of Ontario IT Standards35 ;• IEEE LOM: em 2002 foi endossado pela IEEE 1484.12.1-2002.

O uso de padrões internacionais é fundamental36 quando falamos de interoperabilidadesemântica. No nosso contexto, de tecnologias e sistemas de informação, podemos definir intero-perabilidade como a possibilidade de múltiplos sistemas, com diferentes programas, diferentehardware, e diferentes estruturas de dados e interfaces, trocarem dados, sem comunicação prévia,com o mínimo de perda de conteúdos e de funcionalidade Niso Press (2004).

Há vários níveis de interoperabilidade. Segundo Payette et al. (1999) a interoperabilidadepode ser implementada:

• a nível de uma determinada comunidade ou intra-comunidades;• a nível de uma determinada classificação de informação (p.ex: relatórios de reuniões,catálogos, etc);

• a nível de determinada tecnologia de informação (p.ex: bases de dados relacionais, visuali-zação de dados, etc).

O Marco Europeu de metadados para aplicações paneuropeias37 distingue 3 dimensões para ainteroperabilidade IDABC (2004):

• Organizativa que tem a ver com a forma como as organizações modelam os processos e aforma como cooperam entre si;

• Técnica que tem a ver com aspectos técnicos de ligar computadores e serviços;• Semântica que tem a ver não somente com o facto de como podem os computadores estar

ligados entre si mas também com o facto de a informação a partilhar poder ser interpretadapelas máquinas apesar destas não terem intervido na sua criação.

O IEEE (2010) define interoperabilidade no seu glossário como :

“A capacidade de um sistema ou produto trabalhar com outros sistemas ou produtossem um esfoço especial da parte do cliente. A interoperabilidade é possível atravésda implementação de padrões.”

A DCMI (2011) define interoperabilidade no seu glossário :

“A capacidade de tipos diferentes de computadores, redes, sistemas operativos eaplicações trabalharem em conjunto com eficácia, sem comunicação prévia, de formaa trocarem informação de uma maneira útil e com significado. (...)”

34http://www.tdwg.org/standards/ - acedido em 20 de Junho 201235http://www.mgs.gov.on.ca/en/IAndIT/STEL02_047444.html - acedido em 21 de Julho 201236Mas não suficiente, como será visto mais adiante.37Directiva Europeia 2004/387/CE


http://www.tdwg.org/standards/

http://www.mgs.gov.on.ca/en/IAndIT/STEL02_047444.html


A definição da DCMI retoma a dimensão da definição do Marco Europeu de metadados paraaplicações paneuropeias no que diz respeito à interoperabilidade semântica uma vez que falade “trocar informação com significado“. É esta dimensão que claramente nos interessa, uma vezque é definida num contexto Web onde o significado da informação a ser partilhada é tão oumais importante quanto a própria informação desprovida de significado para a máquina. Estesignificado da informação que se transfere entre agentes diferentes, pode ser retirado e usado aum nível de inteligência artificial. A esta interoperabilidade damos o nome de interoperabiliadesemântica e é a que nos interessa reter.

No caso da WS, quando são adoptados padrões internacionais, eles potenciam ao máximo ainteroperabilidade entre os agentes que comunicam. Isto acontece porque havendo um conjuntode regras definidas (esquemas de metadados), a troca de dados é efectuada segundo essasregras, sem necessidade de entendimento prévio (ou quase nenhum). Segundo o W3C (2012a)“a Web Semântica oferece uma estrutura comum que permite que dados sejam partilhados ereutilizados em todos os limites das aplicações, organizações, e comunidades”. No entanto,sendo fundamental o uso de padrões internacionais, ele não é suficiente para obter um elevadonível de interoperabilidade. De facto, desde a criação do DCMES em 1995 até aos nossosdias, percorreu-se um caminho de procura de soluções para as melhores implementações deinteroperabilidade. Como se verá mais adiante, há vários níveis de interoperabiliade e essa medidadepende de determinadas condições. Já a seguir apresentamos o conceito de PA, um constructoque está intimamente ligado à possibilidade de um agente na Web obter um elevado grau deinteroperabilidade semântica.

2.2.3 Perfil de Aplicação de metadados e interoperabilidade semântica

Durante anos os padrões usados na comunidade bibliotecária permitiram um elevado nível deconsistência de dados, a solução perfeita para implementar interoperabilidade Chan and Zeng(2006). Mesmo antes da existência da Internet, os standards existentes foram sempre a base paraimplementação de perfis. Um exemplo é a comunidade Z39.5038 que criou perfis para refinar ospadrões Baker et al. (2001). Nesse tempo, em 1997, um PA era baseado numa norma. SegundoLynch (1997) um PA era uma técnica que ajudava uma determinada comunidade a refinar anorma para as suas próprias necessidades.

Com o advento da sintaxe RDF, os programadores passaram a ter uma tecnologia para acombinação de elementos individuais de uma variedade de diferentes esquemas de metadados.Foi uma porta aberta para a possibilidade de escolha dos elementos mais apropriados paradescrever os seus recursos Heery and Patel (2000). Há de facto situações em que o DCMES e oDCTERMS, ou outro qualquer esquema de metadados em particular, não é satisfatório, por si só,para descrever os recursos de uma comunidade em específico. Na verdade, embora o DCMES e osDCTERMS cumpram perfeitamente o seu papel no que diz respeito à descrição de recursos emtermos de requisitos mínimos, eles são demasiado genéricos para descrever muitos dos recursosda Web. Esta generalidade pode comprometer a função de descoberta e de reutilização em

38http://www.loc.gov/z3950/agency/ - acedido em 1 de Dezembro de 2011.


http://www.loc.gov/z3950/agency/


diferentes comunidades Nagamori and Sugimoto (2006). Em comunidades específicas é necessárioacrescentar ao DCMES ou aos DCTERMS, outros esquemas de metadados para corresponder anecessidades próprias.

A DCMI39, provavelmente a mais conhecida e mais importante iniciativa a nível mundial noque diz respeito a metadados, para fornecer “uma base para o desenvolvimento de linguagensindependentes de especificação de sintaxe e de restrições” desenvolveu o DCAM Powell et al.(2007). O DCAM apresenta os componentes e os constructos utilizados nos metadados da DCMI.Um destes constructos é o DCAP - “um constructo genérico para desenhar registos de metadados”Baker and Coyle (2009). A definição das regras para construir um DCAP está patente naSingapore Framework for Dublin Core Application Profiles, uma recomendação da DCMI - c.f.Baker et al. (2008)40.

O Enquadramento de Singapura41 é uma sinopse de toda a investigação realizada na comuni-dade de metadados até ao momento da sua elaboração. É um documento de extrema importânciaporque define um enquadramento para implementar interoperabilidade semântica entre diferentescomunidades de prática. As regras dizem que para desenvolver um DCAP é necessário definir:

• Requisitos FuncionaisOs requisitos funcionais de um DCAP descrevem as funcionalidades que um PA deve ter,assim como as funções que estão fora do seu âmbito. Os requisitos funcionais são a base deavaliação do PA em termos de consistência interna e mostram se esse PA é apropriado aouso em determinado contexto ou determinada comunidade.A definição dos requisitos funcionais é obrigatória.

• Modelo de DomínioO modelo de domínio define as entidades básicas descritas pelo PA e as suas relaçõesfundamentais. O propósito do modelo de domínio é definir um rascunho básico do PA. Omodelo de domínio pode ser expresso utilizando apenas texto ou usando uma abordagemmais formal como por exemplo a Unified Model Language (UML) (c.f. Fowler (2004)), ouo modelo Diagrama Entidade-Relacionamento (ER) (c.f. Chen (1978)).A definição do modelo de domínio é obrigatória.

• Description Set ProfileO Description Set Profile (DSP) (c.f. Nilsson (2008)) define o conjunto de elementosde metadados que são instâncias válidas de um PA42. O modelo DSP da DCMI foiprojectado para oferecer uma linguagem simples de restrições para os metadados da DCMI,baseando-se no DCAM. O DSP coloca restrições nos recursos que podem ser descritos porum conjunto de descrição estando em conformidade com o PA, coloca ainda restrições sobreas propriedades que podem ser usadas, e a forma como um valor pode ser referenciado.

39c.f. http://www.dublincore.org - acedido em 25 Março 2014.40A partir de agora referido como “Enquadramento de Singapura”.41Para além do documento do Enquadramento de Singapura, um grupo de trabalho da National International

Standards Office preocupou-se com a qualidade de produção de metadados para colecções digitais e publicou em2007 um guia com um conjunto de boas práticas para a construção de colecções digitais de qualidade (c.f. NISOFramework Working Group (2007)).

42Notar que o DSP está a ser desenvolvido no âmbito da mailing-list Dublin Core Architecture e será colocadobrevemente - à data de 26 de Nov 2012 - com o estatuto de Working Draft.


http://www.dublincore.org


A definição do DSP é obrigatória.• Guias de Utilização

Os guias de utilização descrevem como se aplica o PA e como se utilizam as propriedadesno contexto de aplicação.A definição dos guias de utilização é facultativa.

• Guias de SintaxeOs guias de sintaxe descrevem a forma como devem ser aplicados os esquemas de codificaçãode sintaxe - Syntax Enconding Schemes (SES) - e os esquemas de codificação de vocabulário- Vocabulary Enconding Schemes (VES).A definição dos guias de sintaxe é facultativa.

Há muitos exemplos de desenvolvimento de PA em todo o mundo e em muitas áreas específicas deaplicação, no entanto poucos são os que seguem a Enquadramento de Singapura - c.f. secção 6.3.1para obter mais informações. Os PA que são desenvolvidos segundo as regras deste Enquadramentode Singapura são denomidados de DCAP.

O desenvolvimento de um DCAP é um processo por etapas, onde cada etapa é construída apartir dos resultados da etapa anterior. Podemos verificar isso através da Figura 2.2, que nosapresenta o modelo do DCAP, definido pela DCMI. Aí vemos que o Domain Model (Modelo deDomínio) é construído em cima (built on) dos Functional Requirements (Requisitos Funcionais),que o DSP é construído em cima do Domain Model (Modelo de Domínio), e que os SyntaxGuidelines (Guias de Sintaxe) são construídos em cima do DSP.

Figura 2.2: Modelo do DCAP segundo o Enquadramento de Singapura Baker et al. (2008).

O Enquadramento de Singapura veio organizar a comunidade de implementadores de PA,respondendo a algumas dúvidas que existiam na implementação de PA. Ele é um documentomarco na comunidade de metadados porque ele refere que, se uma comunidade utiliza um DCAPcomo referência para descrever os seus recursos, essa comunidade encontra-se no mais alto nível



de interoperabilidade. De facto, o uso de padrões internacionais é crítico no que diz respeitoà interoperabilidade semântica, mas não é suficiente, uma vez que para atingir altos níveis deinteroperabillidade a comunidade tem de seguir determinadas regras. Estas regras foram definidaspor Nilsson et al. (2009) no modelo de camadas de interoperabilidade (c.f. Figura 2.3). Estemodelo permite-nos saber o alcance de interoperabilidade de uma determinada implementaçãodefinindo quatro níveis de interoperabilidade. Estes quatro níveis, quando falamos de descriçãodos recursos utilizando esquemas de metadados, estão relacionados com o uso dos:

• esquemas de metadados ou vocabulários da DCMI43, nos níveis 1 e 2;• padrões da DCMI, DCAM e DCAP, nos níveis 3 e 4.

Uma comunidade situa-se no:• nível 1 - se partilha esquemas de metadados que são descritos em linguagem natural, sem autilização de nenhum tipo de linguagem da WS (por exemplo RDF), deixando assim delado a possibilidade do processamento automático de dados;

• nível 2 - se utiliza o RDF e esquemas de metadados baseados em RDF (tais como osesquemas de metadados da DCMI ou outros). Isto implica uma definição formal e clara derelacionamentos e regras entre os elementos de forma a que as máquinas possam retirarautomaticamente conclusões;

• nível 3 - se utiliza os seus metadados estruturados de acordo com o DCAM;• nível 4 - se possui um DCAP Nilsson et al. (2009).

Figura 2.3: Níveis de interoperabilidade segundo a Dublin Core Metadata Initiative - Nilsson etal. (2009)

O nível 4 é, segundo a DCMI, o nível mais elevado de interoperabilidade que se pode atingire como vimos, possuir um DCAP para descrever os recursos de uma comunidade é essencialpara atingir esse nível. O DCAP torna-se assim numa figura muito importante no contexto dainteroperabilidade semântica.

Por ser uma figura muito importante no contexto da interoperabilidade semântica, o desen-volvimento de um DCAP deve ser, à semelhança de qualquer outra aplicação, algo realizadocom planos e estrutura. Desejamos, por isso, conhecer os métodos existentes na comunidade demetadados para desenvolvver PA ou DCAP. Por essa razão a secção seguinte apresenta o estado

43DCMES e DCTERMS.



da arte dos métodos para o desenvolvimento de um PA.

2.3 Estado da arte - métodos para o desenvolvimento de umPerfil de Aplicação de metadados

Nesta secção apresentamos o estado da arte dos métodos para o desenvolvimento de um PA.Como introdução fazemos uma clarificação dos conceitos de método, processo, metodologia,ferramenta e técnica, e estabelecemos a relação entre eles. De seguida referimos o âmbito doestado da arte, apresentamos a análise realizada, e ainda uma síntese dos resultados.

2.3.1 Introdução

O desenvolvimento de uma aplicação é um processo demasiado complexo para ser conduzidosem planos nem estrutura; o desenvolvimento de um DCAP não poderá escapar à regra. Wijers(1991) refere que o desenvolvimento de uma aplicação necessita da definição dos tipos de modelosnecessários para a estruturação do problema e da solução; e da definição dos tipos de actividadespara a solução do problema. Estas duas perspectivas (modelos e actividades) correspondem ao“produto” e ao “orientado ao processo“ dos processos de resolução de problemas. Wijers (1991)refere-se então a estas duas dimensões como a ”forma de modelação“ - “way of modeling” nooriginal - e a “forma de trabalho” - “way of working”. A estas duas dimensões acrescenta umaterceira, a “forma de controlo” - “way of controlling” -, e acrescenta porque estando os problemasintegrados numa organização, eles necessitam de formas de definição da equipe de trabalho, doplano de trabalho, da alocação de tarefas, etc. do processo. As formas de modelação definemmétodos e ciclos de vida; e as formas de trabalho utilizam ferramentas e técnicas. É importanteclarificar e integrar todos estes conceitos.

Segundo Brinkkemper (1996), um autor da área dos Sistemas de Informação, “uma ferramentaé uma forma automática de apoiar o desenvolvimento de um processo” (p. 276). Por outro lado,segundo de Almeida and Pinto (1995), autores das Ciências Sociais, técnicas, “são conjuntosde procedimentos bem definidos e transmissíveis, destinados a produzir certos resultados narecolha e tratamento de informação requerida pela actividade” (p. 78). Brinkkemper (1996)segue a mesma linha de pensamento: “a técnica é um procedimento, possivelmente com umanotação bem definida, para realizar o desenvolvimento de uma actividade” (p. 276). “Ummétodo é uma abordagem para realizar um projeto de desenvolvimento de sistemas, baseadonuma forma específica de pensamento, consiste em direcções e regras, estruturadas numa formasistemática de desenvolvimento de actividades com o correspondente desenvolvimento de produtos.”(Brinkkemper, 1996, p. 275-276).

A relação entre técnica e método é apresentada por de Almeida and Pinto (1995): “A selecçãode técnicas, o controlo da sua utilização, a integração dos resultados parciais obtidos, constituemjustamente a função dos métodos (...)” (p. 80). E continuam os mesmos autores dizendo que“compete aos métodos organizar criticamente as práticas (...), sendo o seu campo de influênciaconstituído pelas operações propriamente técnicas, das quais portanto se distinguem” (p. 80).



March and Smith (1995), autores da área dos Sistemas de Informação, apresentam uma definiçãopara método na mesma linha de pensamento: “Um método é um conjunto de passos (umalgoritmo ou guia) utilizados para realizar uma tarefa” (p. 257); Hevner et al. (2004), autorestambém da área dos Sistemas de Informação, também referem um método como algo que defineprocessos, algo que fornece guias para a resolução de problemas. Esses métodos, segundo aindaHevner et al. (2004) “podem ir de algoritmos matemáticos formais que explicitamente definemo processo de pesquisa, a descrições textuais, informais de abordagens de «melhores práticas»”(Hevner et al., 2004, 79).

O termo “ciclo de vida” aparece frequentemente no desenvolvimento de sistemas; sendo umciclo de vida o processo de desenvolvimento das várias fases definidas, com regras para a suaordenação ao longo do tempo. O ciclo de vida não é um método, apesar de definir as fases e suaorganização, não dá indicação das ferramentas, das técnicas, nem como elas se encadeiam e sãocontroladas.

O termo “metodologia” é usado frequentemente na área de Sistemas de Informação como sig-nificando “método”. Brinkkemper (1996) refere existir uma confusão sistemática nesta área entreestes termos, e que esse facto é revelador da imaturidade da área44; continua dizendo que o mauuso do termo deveria ser definitivamente abandonado. Na verdade de Almeida and Pinto (1995)definem “metodologia” como “a organização crítica das práticas de investigação” (de Almeidaand Pinto, 1995, p. 84). “A metodologia alimentar-se-á (...) dos métodos, dos percursos já feitos,retirando deles a novidade produtiva. É uma aprendizagem e uma sistematização posteriorísticados conceitos processuais e das suas relações” (de Almeida and Pinto, 1995, p. 85). Brinkkemper(1996) define metodologia como “o estudo sistemático, a explicação e avaliação de todos osaspectos do desenvolvimento metódico de sistemas de informação” (Brinkkemper, 1996, p. 276),na realidade uma definição igual à dos autores de Ciências Sociais já referidos. Na mesma linhade pensamento está Tolvanen (1998), também autor da área dos Sistemas de Informação; elerefere que metodologia é o estudo dos métodos. Vemos então que uma metodologia é o caminhocrítico desenvolvido pelo investigador para a construção de um método, seja na área de CiênciasSociais, seja na área de Sistemas de Informação.

Sendo um DCAP um constructo tão importante na comunidade de metadados, quisemossaber quais as formas de modelação, de trabalho e de controlo existentes na comunidade demetadados para o desenvolvimento de PA ou DCAP.

Com esse objectivo em mente, realizamos o estudo do estado da arte dos métodos existentesna comunidade científica para o desenvolvimento de PA45. Muitos autores analisados nesteestudo utilizaram a palavra “metodologia” para descrever as formas de modelação, de trabalho,e de controlo dos sistemas; outros utilizaram a palavra “método”. Todos eles foram analisados damesma forma e contribuiram para os resultados do nosso estudo.

44Citando, no original: “The misuse of the term methodology standing for method is a sign of the immaturityof our field, and should consequently be abandoned” (Brinkkemper, 1996, p. 276).

45Este trabalho deu origem ao artigo apresentado no congresso Metadata Semantics Research 2012 - Cu-rado Malta and Baptista (2012b) - artigo mais tarde seleccionado para fazer parte de uma edição especial darevista International Journal of Metadata, Semantics and Ontologies - c.f. Curado Malta and Baptista (2013d).



2.3.2 Âmbito do estudo

É importante definir os limites deste estudo no que diz respeito ao conceito de PA. Desde adefinição de Lynch (1997) em 1997 até à definição de Baker et al. (2008) podemos ver umaevolução clara (ver Tabela 2.1):

• Lynch (1997) define um PA como um refinamento de um padrão;• Herry and Patel (2000) em 2000 vão para além disso e definem um PA como uma “misturae conjugação” Heery and Patel (2000)46 de diferentes esquemas de metadados;

• Finalmente Baker et al. (2008) (Enquadramento de Singapura) em 2008 definem regrasmais consistentes para construir PA, realizando um trabalho em coordenação com a DCMI.Passa-se a olhar para o desenvolvimento de um PA como um processo, acrescentando àabordagem de Heery and Patel (2000): a necessidade de descrever as diferentes propriedadese restrições dos esquemas de metadados através da utilização da linguagem de restriçõesDSP - ver Nilsson (2008); a necessidade de definir requisitos funcionais e um modelode domínio de forma a forçar os desenvolvedores de PA a criar melhores processos dedesenvolvimento; e ainda a necessidade, ainda que não obrigatória, do desenvolvimento deguias de forma a dotar os implementadores de PA com documentação de apoio ao processo.O Enquadramento de Singapura é um marco. A partir desse momento aparece o conceitode DCAP, sendo estes os PA que respeitam o Enquadramento de Singapura.

Os PA seleccionados no estudo efectuado e relatado já na secção seguinte, são aqueles que seenquadram em qualquer das definições anteriormente apresentadas.

2.3.3 Análise

Seguem-se os resultados encontrados em cada categoria.

2.3.3.1 Manuais

Os MANUAIS encontrados são:

• Chen and Chen (2005) : O Modelo do ciclo de vida dos metadados (Metadata LifecycleModel) é um modelo para a aplicação de metadados em bibliotecas digitais Chen and Chen(2005) com 4 fases:

1. Análise de requisitos e análise de conteúdo:– Aquisição de necessidades base de metadados;– Análise de esquemas de metadados padrão e projectos relevantes;– Investigação das necessidades profundas de metadados;– Identificação de estratégias para os esquemas de metadados e interoperabilidade

com padrões bem conhecidos de metadados.2. Especificação de requisitos de sistema;

– Preparação da especificação de equisitos de metadados;– Avaliação de sistemas de metadados.

46“mixing and matching”.



Tabela 2.1: A evolução do conceito de Perfil de Aplicação de metadados na comunidade demetadados.

Fonte Breve descrição ComentáriosLynch(1997)

Um PA baseia-se num padrão,e é uma técnica que ajuda umadeterminada comunidade a re-finar o padrão às suas necessi-dades.

Refinar um padrão existente.

Heery e Pa-tel (2000)

Elementos de dados retiradosde um ou mais esquemas demetadados combinados por im-plementadores e optimizadospara um aplicação local espe-cífica.

A possibilidade de “misturar e combinar” dife-rentes esquemas de metadados.

Baker et al.(2008)

O desenvolvimento de um PApassa a ser um processo orde-nado, composto pelo desenvol-vimento de: Requisitos fun-cionais; Modelo de domínio;DSP; Guia de utilização doPA; Guia de codificação de sin-taxe

Uma definição mais abrangente, adicionando anecessidade de utilizar a linguagem de restriçõesDSP para descrever o PA; a necessidade de de-finir requisitos funcionais e modelo de domíniopara forçar as pessoas que desenvolveram DCAP,a ter melhores processos de desenvolvimento; ea necessidade de criar documentação (ainda quenão obrigatória) ajudando os implementadores ater suporte documental para o processo de im-plementação do PA. Aparece o termo DCAP:aqueles PA que respeitam o Enquadramento deSingapura.

3. Sistema de metadados;– Preparação de guias de melhores práticas;– Desenvolvimento do sistema de metadados.

4. Serviço e avaliação– Manutenção do serviço de metadados;– Avaliação do desempenho de metadados.

Passos: SimComo: NãoCobertura: n/d

• BSI (2005) : Este manual de 2005 apresenta recomendações na criação de perfis deaplicação. Baseia-se nos padrões DC e IEEE LOM e é desenvolvido para o domínio doensino e aprendizagem BSI (2005). Podemos resumir da seguinte forma a metodologiaapresentada para o desenvolvimento dos PA:

1. Reunir os requisitos;2. Identificar esquemas de metadados apropriados;3. Selecionar os elementos de metadados;



4. Especificar regras para os elementos de metadados;5. Revisão relativamente a outros requisitos;6. Finalizar o projecto;7. Desenvolver os crosswalks necessários;8. Requisitos para o binding Extensible Markup Language (XML);9. Desenvolver um plano de manutenção.


• IMS Global Learning Consortium (2005a) (2005b) : Estes documentos de 2005, desenvolvi-dos pelo IMS Global Learning Consortium, especificam os passos de desenvolvimento de umPA. A parte 1 do documento debruça-se sobre aspectos mais relacionados com a gestão doprocesso e metodologia, enquanto que a parte 2 do documento é conteúdo exclusivamentetécnico. A parte 1 possui uma secção, de nome “Esboço de um processo para criar umPA”, onde apresenta de uma forma global uma metodologia para o desenvolvimento de umPA no domínio dos recursos educativos. Esta secção divide-se em:

1. Análise de viabilidade e risco: identificação dos stakeholders, análise da dimensão domercado ao qual o PA se destina para entender se está efectivamente disponível parao aplicar;

2. Captura de requisitos: identificação dos requisitos específicos da comunidade que iráusar o PA;

3. Definir as regras para tomada de decisão: este ponto tem mais a ver com a gestão dogrupo de trabalho do que com o desenvolvimento de um PA;

4. Desenvolvimento do PA: Directrizes: Identificação de cenários, construção de casos,desenvolver tendo como base as especificações definidas na captura de requisitos.

Este documento tem ainda um conjunto de regras definidas para o desenvolvimento de umPA que encontraremos de novo nos documentos referidos de seguida, e que tem a ver comquestões de conformidade com o esquema base dos PA.Passos: SimComo: SimCobertura: 1

• CWA (2006): Este manual, que é desenvolvido em 2006 pelo comité europeu para asantardização, é um guia para o desenvolvimento de PA na área do e-learning. As regrassão:

1. Começar pelos requisitos próprios;2. Definir os elementos de metadados: selecção dos elementos de dados; definição do

tamanho e do valor mínimo-máximo; elementos de múltimos esquemas de metadados;adicionar elementos locais;

3. Obrigatoriedade de elementos de metadados;



4. Domínio dos elementos de metadados;5. Relações e dependências entre elementos de metadados;6. Tipos de dados;7. Binding.

Passos: SimComo: SimCobertura: 1

• Baker et al. (2008): O Enquadramento de Singapura, de 2008, define um DCAP e apresentaregras para o seu desenvolvimento:

1. Requisitos funcionais: descreve o que uma comunidade deseja realizar com a suaaplicação;

2. Modelo de domínio: caracteriza o tipo de “coisas” que os metadados descrevem e asrelações entre essas “coisas”;

3. Perfil descritivo DSP e regras de utilização: enumera os termos de metadados a usare as regras para o seu uso, e;

4. Regras de sintaxe e formato dos dados: descreve a sintaxe máquina que será usadapara codificar os dados.


2.3.3.2 Artigos Metodológicos

Os artigos metodológicos são:

• Duval et al. (2002): Neste artigo fundador de 2002, os autores apresentam práticas demetadados, sendo uma delas o PA. À semelhança do documento de Baker et al. (2008),apresentam regras e questões fundamentais, mas não falam de todo em qualquer tipo demetodologia ou “forma processual de fazer”. Este documento contribui posteriormente cominformação presente no guia CWA (2006) já referido anteriormente;Passos: NãoComo: NãoCobertura: n/d

• Friesen et al. (2002): Neste artigo de 2002, os autores baseiam-se na análise de doisPA (TLF e CanCore) para apresentar um conjunto de “formas de fazer” importantes naimplementação de um PA na área dos recursos educativos, mas não apresentam nenhumametodologia. Os pontos são: os modelos de informação dos esquemas de metadados emque se baseia o TLF são diferentes (DC e IEEE LOM). Um passo importante para odesenvolvimento deste PA foi a unificação destes modelos de informação; clara explicação esimplificação do modelo de dados; utilização de modelos de boas práticas; utilização, tanto



quanto possível, de esquemas de metadados padrão; utilização de formas incrementais paraatingir o objectivo final de interoperabilidade.Passos: SimComo: SimCobertura: 1

• Currie et al. (2002): Este artigo de 2002 apresenta um método para tornar a “interoperabili-dade visível”, a abordagem dos autores é a de agregar todos os elementos de metadados dascolecções de recursos, considerar os processos que poderiam ser utilizados para racionalizaro conjunto agregado de elementos e, em seguida, mostrar como as organizações podemtrabalhar em conjunto para harmonizar o perfil aplicativo resultante. Este processo éreferido como “ARH - HA¡‘: Visualizar os processos de agregação, racionalizar e harmonizara fim de motivar as organizações a harmonizar conjuntos heterogéneos distribuidos derecursos que possuem em comum.Passos: NãoComo: SimCobertura: 1

• EESV (2012) : O projecto europeu Interoperability Solutions for European Public Admi-nistrations (ISA), que desenvolveu o PA Asset Description Metadata Schema (ADMS),na sua documentação de 2012 apresenta um documento dedicado à metodologia de desen-volvimento, no entanto o documento tem mais a ver com uma metodologia de gestão degrupos multi-culturais e distribuídos geograficamente, do que com uma metodologia dedesenvolvimento do seu PA.Passos: NãoComo: SimCobertura: 1

2.3.3.3 Artigos Perfis

Os artigos perfis são:

• DCMI (nd): Neste projecto da DCMI é proposto a utilização de cenários no desenvolvimentodo PA.Passos: NãoComo: SimCobertura: 1

• Onyancha et al. (2001): Este artigo de 2001 apresenta o desenvolvimento do PA AGRIS.Nele refere a metologia aplicada (Onyancha et al., 2001, pag. 7):

1. Desenvolvimento de um mapa conceptual dos diferentes tipos de recursos de informaçãoutilizada no portal do projecto;

2. Remodelação do modelo de dados do portal do projecto para atender à necessidadesactuais de informação;



3. Avaliação dos standards e práticas comuns para descrição de recursos;4. Mapeamento dos elementos utilizados para os standards;5. Desenvolvimento dos elementos adicionais;6. Desenvolvimento do binding.

Passos: NãoComo: NãoCobertura: n/d

• Agostinho et al. (2004): Este artigo de 2004, que refere o desenvolvimento do PA LOMAPdo domínio dos recursos educativos (learning objects), descreve a metolodogia aplicada noseu desenvolvimento:

1. Revisão de literatura dos PA existentes do domínio dos recursos educativos;2. Escolha de uma base de esquema de elementos de metadados;3. Aplicação dos elementos do esquema de metadados base a um conjunto de recursos

educativos para entender as forças e debilidades desses elementos, e para retirar asquestões decorrentes da aplicação da base escolhida. Este passo teve duas etapas:(i) Na etapa 1, investigadores fizeram uma revisão de uma amostra de objectos deaprendizagem aos quais aplicaram os elementos do esquema de metadados escolhido eretiraram conclusões; (ii) Na etapa 2, os mesmos investigadores responderam a umconjunto de questões. Estas questões foram concebidos para capturar informação queos investigadores consideram útil, permitindo-lhes desenvolver descrições dos objectosde aprendizagem, para fornecer estas descrições aos metadados;

4. Os resultados de ambas as etapas do passo anterior são reunidos e comparados;5. Aplicação de um perfil de aplicação já existente a uma amostra de objectos de

aprendizagem;6. Análise do ponto anterior;7. Com base nos pontos anteriores, desenvolvimento do PA.


• de La Passadiere and Jarraud (2004): Neste artigo de 2004 é descrito o desenvolvimentodo perfil de aplicação ManUel. Para isso é aplicada a metodologia que é baseada no estudodas necessidades dos utilizadores e da comunidade de prática à qual se destina o PA. Ametodologia tem as seguintes etapas (de La Passadière and Jarraud, 2004, pag. 10):

1. Estudo das necessidades: consulta às diferentes comunidades de utilizadores; estudode normas;

2. Elaboração de uma solução: princípios adoptados; escolhas efectuadas;3. Posta em prática da solução: definição do PA.

Passos: SimComo: Não



Cobertura: n/d

• Marzal Garcıa-Quismondo et al. (2006): Este artigo de 2006 apresenta o desenvolvimento doperfil de aplicação MIMETA, na área dos recursos educativos. A metodologia apresentadabaseia-se tanto na metodologia apresentada por Agostinho et al. (2004) como por Chenand Chen (2005) (Marzal García-Quismondo et al., 2006, pag. 553):

1. Revisão da literatura existente sobre metadados educacional e análise dos standards edas especificações principais desenvolvidas no domínio das tecnologias de ensino;

2. Análise dos principais projectos educacionais de bibliotecas digitais, onde os esquemasdetectados no ponto anterior são aplicados;

3. Desenvolver um PA a partir dos standards mais importantes identificados anteri-ormente. Inicialmente são escolhidos os elementos de metadados de característicasgenéricas. Depois passa-se à escolha dos elementos de metadados de mais detalhe;

4. Análise dos elementos de metadados contidos nos projectos analisados; realização detriagem;

5. Finalização do PA tendo como base as recolhas e selecções efectuadas anteriormente.


• Wilson et al. (2007): Este artigo de 2007 refere o documento BSI (2005) como a base paraa metodologia implementada (Wilson et al., 2007, pag. 7).

1. Reunir os requisitos;2. Identificar os esquemas apropriados;3. Seleccionar elementos de dados;4. Especificar regras para elementos de dados;5. Revisão em relação a outros requisitos;6. Finalizar a versão rascunho;7. Criar crosswalks;8. Requisitos para o XML Binding;9. Desenvolver um plano de manutenção.


• Buonazia and Masci (2007): Este artigo de 2007 descreve o desenvolvimento do projectoCultura Italia que contém o desenvolvimento do PA PICO. Este documento possui umasecção sobre a metologia aplicada no desenvolvimento. Ela resume-se a:

1. Análise dos potenciais utilizadores do portal e do domínio de aplicação;2. Definição de cenários de utilizadores (as diferentes abordagens ao portal) e casos de

utilização;



3. Desenho da arquitectura do portal;4. Análise de conteúdos;5. Análise do estado da arte em esquemas de metadados descritivos;6. Desenvolvimento do esquema de metadados (Buonazia and Masci, 2007, pag. 394).

A metologia contém mais pontos no entanto não estão relacionados com o desenvolvimentodo PA.Passos: SimComo: SimCobertura: 1

• Eadie (2008): Neste artigo de 2008 é referido, na introdução do artigo, que foi constituidoum grupo de trabalho contendo pessoas com backgrounds distintos relacionados com odomínio de aplicação do PA. Refere ainda que o grupo comunicou via uma mailing list.Termina dizendo que quando o projecto estiver quase no seu final têm a intenção de alargara discussão a um grupo consultivo maior. Apresenta o plano de trabalho:

1. Desenvolvimento draft dos requisitos funcionais;2. Desenvolvimento do Diagrama Entidade-Relacionamento draft e o conjunto de atribu-

tos;3. Desenvolvimento draft do PA;4. Discussão de grupos;5. Refinamento do PA com os dados provenientes da discussão de grupos;6. Desenvolvimento de guias de catalogação simples para a utilização do PA;7. Apresentação dos trabalhos à comunidade;8. Desenvolvimento dos planos de aceitação por parte da comunidade.


• Salokhe et al. (2008): Este artigo de 2008 descreve o desenvolvimento do PA ”Organization“.A metodologia utilizada para o seu desenvolvimento foi:

1. Definição do projecto, do seu objectivo e contexto;2. Avaliação dos standards de metadados existentes e criação do esquema de metadados;3. Comparar cada elemento definido com os elementos do standard ISO11179;4. Desenvolvimento do binding em XML5. Teste dos dados reais com o binding definido no ponto anterior;6. Desenvolvimento do guia de utilização (Salokhe et al., 2008, pag. 3).


• Bountouri et al. (2009): Este artigo de 2009 tem uma secção para a apresentação da



metodologia de implementação do PSI AP. Ela é no entanto muito geral. Resume-se a:

1. Comparação de cada esquema de metadados base (esquemas estes do domínio de apli-cação do futuro PA) com o esquema DC; adição de propriedades e de sub-propriedadesextra;

2. Resolução semântica e harmonização das propriedades e sub-propriedades3. Especificação do PSI AP (Bountouri et al., 2009, pag.4).


• Palavitsinis et al. (2009): Este artigo de 2009 apresenta o desenvolvimento do PA ”Or-ganic.Edunet”. Na secção “processo genérico para o desenvolvimento de um PA” refereos passos genéricos (generic steps) utilizados para o seu desenvolvimento. Passamos adescrever:

1. Definição dos requisitos próprios;2. Selecção dos elementos LOM;3. Refinamento semântico (de forma a servir melhor as necessidades próprias do Orga-

nic.Edunet);4. Especifição dos constrangimentos e dos domínios dos elementos;5. Especificação das relações e dependências entre elementos;6. Introdução dos elementos para responder a necessidades específicas;7. Finalização do PA (que inclui o binding e questões tecnológicas de como os metadados

são obtidos, criados e guardados).


• Zschocke et al. (2009): Este artigo de 2009 descreve o desenvolvimento do PA CIGAR,no domínio dos recursos educativos (learning objects), este PA tem como público alvouma comunidade distribuída e multi-idioma. Este artigo descreve que foi realizada umarevisão de diferentes PA LOM para identificar os elementos obrigatórios LOM utilizadosna implementação de PA de outras organizações. Isso ajudou a entender melhor qual osub-conjunto de elementos que são normalmente utilizados para descrever as característicasbásicas de recursos de aprendizagem e como isso poderia orientar o desenvolvimento do PACGIAR para os seus próprios recursos. Devido à natureza internacional e distribuída dacomunidade, o suporte para vários idiomas foi considerado essencial (Zschocke et al., 2009,pag. 16).Passos: SimComo: SimCobertura: 1.



2.3.4 Síntese

A Tabela 2.2 apresenta o resumo da informação retirada dos 21 items analisados. Constata-seque somente 9 dos items têm informação de como desenvolver um PA, mas todos eles foramclassificados como “parcialmente coberto” no que diz respeito à escala de cobertura.

Baker et al. (2008) definiram o documento mais completo no que diz respeito às regras parao desenvolvimento de um DCAP, mas não indica como cada parte desse desenvolvimento deveser realizado.

Há um conjunto de pequenas directrizes encontradas nos documentos examinados que sãointeressantes reter para o trabalho de definição do método para o desenvolvimento de DCAP (c.f.capítulo 5). Essas directrizes são apresentadas na secção 4.1.1; elas foram retiradas em especialdos documentos categorizados como “Artigos perfis”, mais focados num domínio em particular.

Tabela 2.2: Sumário dos resultados obtidos na análise do estado da arte dos métodos dedesenvolvimento de Perfis de Aaplicação de metadados.

Item Como Passos CoberturaManuaisChen and Chen (2005) Sim Não n/dBSI (2005) Sim Não n/dIMS Global Learning Consortium (2005a)(2005b)

Sim Sim 1

CWA (2006) Sim Sim 1Baker et al. (2008) Sim Não n/dArtigos MetodológicosDuval et al. (2002) Não Não n/dFriesen et al. (2002) Sim Sim 1Currie et al. (2002) Não Sim 1EESV (2012) Não Sim 1Artigos PerfisDCMI (n/d) Não Sim 1Onyancha et al. (2001) Não Não n/dAgostinho et al. (2004) Sim Sim 1de La Passadiere and Jarraud (2004) Sim Não n/dMarzal Garcıa-Quismondo et al. (2006) Sim Não n/dWilson et al. (2007) Sim Não n/dBuonazia and Masci (2007) Sim Sim 1Eadie (2008) Sim Sim 1Salokhe et al. (2008) Sim Não n/dBountouri et al. (2009) Sim Não n/dPalavitsinis et al. (2009) Sim Não n/dZschocke et al. (2009) Sim Sim 1



2.3.5 Conclusões

Esta secção tem como objectivo a apresentação do estudo do estado da arte dos métodos para odesenvolvimento de perfis de aplicação de metadados. Para o estudo do estado da arte realizamos(i) uma revisão de literatura consultando bases de dados online, realizando pesquisas no motor debusca Google e em mailing lists, e analisamos ainda documentação técnica dos PA encontrados;(ii) a análise de PA que conseguimos encontrar na referida revisão de literatura. Os resultadosdeste estudo revelaram que não existe nenhum método, tanto quanto conseguimos apurar, para odesenvolvimento de PA ou DCAP. Encontrámos pequenas fórmulas ou “receitas” particularespara etapas muito específicas, mas nenhuma fundamentada e pormenorizada. Encontrámostambém guias demasiado globais com linhas mestras, mas não suficientemente detalhadas para onecessário desenvolvimento do PA ou DCAP. Até agora os PA e DCAP foram desenvolvidos pordiferentes grupos de pessoas, utilizando diferentes abordagens e técnicas, e como vimos, pouco ounada foi publicado. Não existe nenhuma publicação sobre as formas de modelação, de trabalho ede controlo do processo de desenvolvimento de DCAP.

Torna-se imperativo a definição de um método para o desenvolvimento de um DCAP, pois eleé uma ferramenta indispensável da comunidade de metadados, já que um DCAP é um modelode dados muito importante para o desenvolvimento de interoperabilidade semântica no âmbitoda WS. A falta de um tal enquadramento é uma lacuna na comunidade de metadados.

Iremos contribuir para a definição de um método para o desenvolvimento de DCAP de formaa resolver o problema encontrado. É esse o propósito do nosso trabalho de investigação.

2.4 Sumário

Este capítulo tem como objectivo (i) a apresentação do enquadramento teórico que suporta osconceitos basilares necessários ao desenvolvimento do nosso trabalho de doutoramento e ainda;(ii) o estudo do estado da arte dos métodos para o desenvolvimento de perfis de aplicação demetadados.

Começamos por balizar o enquadramento teórico no paradigma da WS. De seguida apre-sentamos os conceitos de metadados e de esquemas de metadados, ligando-os ao paradigmareferido; apresentamos ainda os constructos definidos pela DCMI que suportam as aplicaçõesda Web Semântica: o DCAM e o DCAP. A primeira parte deste capítulo culmina na secção deexposição sobre os conceito de interoperabilidade e de interoperabilidade semântica, ligando-osao constructo DCAP, apresentando a importância de uma comunidade possuir um DCAP deforma a poder implementar aplicações na WS semanticamente interoperáveis.

Tratando-se o DCAP de um constructo de muita importância, é importante saber quais osmétodos existentes na comunidade para o desenvolvimento de DCAP. Esse é o objecto de estudoda segunda parte deste capítulo.Na segunda parte deste capítulo apresentamos o estado da arte dos métodos para o desenvolvi-mento de perfis de aplicação de metadados. Detalhamos as práticas da comunidade de metadadosrelativamente ao desenvolvimento do referido constructo, e concluimos que de facto, tanto quanto



conseguimos apurar, não existe nenhum método que explique a forma como se desenvolve umperfil de aplicação de metadados. Este é o nosso problema de investigação. Nos próximoscapítulos apresentamos o trabalho que desenvolvemos com o sentido de resolver este problema.


Capítulo 3

Metodologia de investigação

COMPLETEOnly after many completions of cycles can then be wisdom

Deng Ming-Dao

Este capítulo apresenta a metodologia de investigação utilizada no nosso trabalho. Ele inicia-secom uma breve resenha sobre metodologias de investigação no sentido de clarificar conceitos.Nesta breve resenha apresentamos muito brevemente as metodologias quantitativas e as técnicasquantitativas de recolha de dados, as metodologias qualitativas e as técnicas qualitativas derecolha de dados, e ainda, as circunstâncias em que uma e outra são utilizadas. Terminamosesta primeira secção identificando as técnicas de recolha de dados, bem como as técnicas deanálise de dados utilizadas no nosso trabalho de investigação. Na secção seguinte introduzimos aDesign Science Research (DSR), a metodologia de investigação por nós utilizada. E de seguidaapresentamos o enquadramento em que trabalhamos, os três ciclos de Hevner (2007). Na últimasecção deste capítulo é apresentada a aplicação específica do enquadramento de Hevner (2007)ao nosso trabalho, onde resumimos os trabalhos por nós efectuados em cada “Espaço” definidopor Hevner (2007).

3.1 Breve resenha sobre metodologias de investigação

As metodologias quantitativas foram orginalmente desenvolvidas nas Ciências Naturais paraestudar fenómenos (por exemplo: por que cai uma maçã?) Myers (1997). Exemplos de metodolo-gias quantitativas são as experiências laboratoriais, os métodos numéricos como por exemplomodelação matemática ou os inquéritos Myers (1997). As técnicas quantitativas recolhem dadosatravés de instrumentos, onde podem fazer testes e medições; ou recolhem informação numacheclist (por exemplo de uma observação de alguém a trabalhar). São dados numéricos ouinformação recolhida em escalas previamente definidas Creswell (2003).

Somente um número limitado de factores pode ser estudado em condições laboratoriais, sendodifícil por vezes reproduzir algumas situações do “mundo real”. Por essa razão, as Ciências Sociaisdesenvolveram as metodologias qualitativas Galliers and Land (1987) de forma a poderem estudar

35

3. Metodologia de investigação

fenómenos sociais e culturais Myers (1997). Exemplos de metodologias qualitativas são o Estudode Caso, a Etnografia, a Ground Theory ou a DSR, utilizada no nosso projecto de investigação.As técnicas qualitativas de recolhas de dados são, por exemplo, a observação participante, asentrevistas, ou a análise de documentos ou textos Myers (1997).

A investigação qualitativa é também exploratória; é útil quando o investigador não conheceas variáveis importantes a serem estudadas. Isto acontece quando se trata de um problema novoCreswell (2003).

Um trabalho de investigação pode utilizar tanto técnicas de recolha de dados qualitativascomo quantitativas. Reconhecendo que todos estas técnicas, seja quantitativas ou qualitativas,têm limitações, uma forma de as neutralizar é a de realizar a triangulação dos dados, istoé, combinar as várias técnicas de recolha de informação num só trabalho de investigação. Atriangulação das fontes de dados é uma forma de usar o que de melhor há nos dois tipos detécnicas Creswell (2003).

No nosso trabalho utilizamos as seguintes técnicas de recolha de material empírico:• Entrevistas exploratórias semi-estruturadas a líderes de organizações de Economia Social eSolidária (ESS) que possuem Sistemas de Informação Web (SIW), de forma a entender arealidade dos SIW da ESS. De facto não havia sido feito até à data nenhum estudo sobreesse tema (c.f. Secção 6.2.2.4.2).

• Entrevistas exploratórias semi-estruturadas a algumas pessoas que desenvolveram DCAPpara conhecer as práticas de desenvolvimento de DCAP (c.f. Apêndice D) .

• Análise de artigos, manuais técnicos, livros e outro tipo de documentos, quer para conheceras práticas de desenvolvimento de PA (c.f. Secção 2.3), quer para analisar os processos emétodos de desenvolvimento de software (c.f. Secção 4.2.1);

• Organização de um grupo de discussão de validação da V0.1 do Método para o desen-volvimento de Dublin Core Application Profiles (Me4DCAP) numa sessão da conferênciaElPUB-2013 (c.f. Apêndice F);

• Organização de um Focus Group (FG) de validação da V0.2 do Me4DCAP, acompanhadode um inquérito por questionário aos participantes.

Do ponto de vista das técnicas de tratamento da informação, todos os materiais recolhidosforam alvo de gravação audio, no caso do FG de gravação vídeo. A informação recolhido foimaioritariamente transcrita e toda ela alvo de uma análise de conteúdo cujas categorias foramconstruídas à medida que foram emergindo no discurso dos diferentes interlocutores. Note-seque, no caso do inquérito, a informação serviu para efeitos de triangulação de dados. No entantonão foi alvo de uma análise quantitativa dado que a amostra era demasiado pequena.

3.2 Design Science Research - Fundamentação

Iniciamos esta secção com apresentação geral da metodologia de investigação DSR. Uma vezque há vários enquadramentos para esta metodologia na área dos Sistemas de Informação,apresentamos no seguimento o enquadramento particular por nós utilizado, os 3 ciclos de Hevner



(2007). Terminamos a secção apresentando a aplicação específica deste enquadramento no nossotrabalho de investigação, onde referimos os trabalhos por nós efectuados em cada “Espaço”definido por Hevner (2007).

3.2.1 Design Science Research

Segundo March and Smith (1995), a Ciência Natural é descriptiva e explicativa: tenta compreendera realidade, e está preocupada em explicar o “como” e o “porquê” dessa realidade. Em contraste,a Design Science “tenta compreender as coisas que servem o ser humano” (March and Smith,1995, pag. 253), e tem como objectivo o desenvolvimento de artefactos inovadores que resolvemproblemas da vida real Simon (1996). Por essa razão a Design Science é intrinsecamente umprocesso de resolução de problemas” (Hevner et al., 2004, p. 82). Gregor and Hevner (2013)referem também estas duas formas de “consumir e produzir conhecimento” (Gregor and Hevner,2013, pag. 343 ) no processo DSR, e dão a cada uma delas uma designação:

• Conhecimento descritivoConhecimento produzido nas Ciências Naturais (o “como” e “porquê” de March and Smith(1995)) e;

• Conhecimento perspectivoO conhecimento produzido na Design Science (o “compreender as coisas que servem o serhumano” de March and Smith (1995))

Um artefacto é algo de artificial construído por humanos Hevner and Chatterjee (2010);em contraponto o “natural” é algo que acontece na natureza Simon (1996); Gregor and Jones(2007). Segundo March and Smith (1995) a Design Science “fornece receitas e cria artefactosque incorporam essas receitas” [pag. 254]. Os cientistas de Design Science ao contrário dedefinir teorias - como os cientistas das Ciências Naturais - criam antes “modelos, métodos eimplementações que são inovadoras e têm valor” (March and Smith, 1995, pag. 254). SegundoMarch and Smith (1995) e Hevner (2007) um projecto de investigação utilizando DSR produzartefactos que podem ser tanto constructos, modelos, métodos ou uma instância de um dostrês. Uma instância operacionaliza um destes três possíveis artefactos e “demonstra tambéma viabilidade e efectividade dos modelos e métodos que ela contém” (March and Smith, 1995,pag. 258). Todos estes artefactos “têm uma intenção de afectar os fenómenos no mundo real”(Purao, 2013, pag. 18), “eles devem melhorar soluções existentes para o problema, ou forneceruma primeira solução para um problema importante” (Hevner and Chatterjee, 2010, pag.6).Purao (2002) e Rossi and Sein (2003), citados por Vaishnavi e Kuechler (2012), referem aindaum quinto tipo de resultado para os projectos que utilizam um DSR: melhores teorias. A “fasede construção de um esforço de DSR pode ser uma prova experimental de um método ou umaexploração experimental ou ambos” Vaishnavi and Kuechler (2012). Na verdade Takeda et al.(1990), citado por Vaishnavi e Kuechler (2012), apresentam uma teoria sobre o raciocínio noprocesso de construção de conhecimento que diz que esse conhecimento vem do acto específico deconstrução.



Segundo March and Smith (1995) a DSR vive na interacção da Design Science e das CiênciasNaturais. As duas actividades básicas das Ciências Naturais são “teorizar” e “justificar” e,as duas actividades básicas da “Design Science” são “construir” um artefacto e “avaliar” esseartefacto. Um processo de DSR “constroi” portanto “artefactos, e avalia-os; teoriza sobre estesartefactos e justifica essas teorias” (March and Smith, 1995, pag. 256); as teorias são o resultadoda investigação que o artefacto traz encapsulado nele. Precisamos de entender “por que” e “como”o artefacto funciona - essas são as teorias. Precisamos de justificar essas teorias, isto é, recolherprovas para as testar March and Smith (1995).

Gregor and Hevner (2013) apresentam um enquadramento para caracterizar e posicionar osprojectos de DSR quanto à contribuição de conhecimento (ver Figura 3.1).

Figura 3.1: Framework definida por Gregor and Hevner (2013) apresentando a contribuição parao conhecimento de um projecto de DSR.

Um projecto pode ser avaliado segundo a maturidade do problema e a maturidade da solução.Os autores definem um gráfico em que no eixo dos XX se situa a maturidade decrescente doproblema e no eixo dos YY a maturidade decrescente da solução1. Existem 4 quadrantes:

• Quadrante de alta maturidade em ambas as medidas (canto inferior esquerdo): trata-se deaplicar soluções conhecidas a problemas conhecidos. Os autores chamam a este quadranteRoutine Design - Design de Rotina. Este quadrante não traz nenhum contributo à basede conhecimento e não apresenta de facto qualquer oportunidade de investigação já que éconhecimento existente que se aplica a situações de rotina.

• Quadrante de alta maturidade no conhecimento do problema e de baixa maturidade no1Ter em atenção que os eixos estão ordenados de “high” para “low”.



conhecimento da solução: trata-se de desenvolver novas soluções para problemas antigos.Os autores chamam a este quadrante, o quadrante Improvement - Melhoria. Este quadranteé uma oportunidade de investigação e traz possíveis contributos à base de conhecimento.

• Quadrante de baixa maturidade no conhecimento do problema e de alta maturidade noconhecimento da solução: trata-se de extender soluções conhecidas a novos problemas. Osautores chamam a este quadrante, o quadrante Exaptation - Exaptação2. Este quadrante éuma oportunidade de investigação e traz possíveis contributos à base de conhecimento.

• Quadrante de baixa maturidade em ambas as medidas: trata-se de inventar novas soluçõespara novos problemas. Os autores chamam a este quadrante, o quadrante Inventions -Invenções. Este quadrante é uma oportunidade de investigação e traz contributos à basede conhecimento. É um quadrante onde há um verdadeiro começar do nada; no entanto, asinvenções são raras e os inventores ainda mais raros.

Posicionamos a nossa investigação no quadrante “Exaptação”. Temos como objectivo contribuirpara a definição de um Método, um dos três tipos de artefactos definidos por March and Smith(1995) e Hevner (2007) como resultados de um processo de DSR, para o desenvolvimento deDCAP. Um método no contexto de um problema novo: a não existência de um enquadramentometodológico para o desenvolvimento de um DCAP. O método é desenvolvido a partir da“extensão” da panóplia de soluções já existentes num contexto distinto mas semelhante - aEngenharia de software. Essas extensões são realizadas através da adaptação de soluçõesconhecidas à situação particular do contexto em que nos situamos - um contexto totalmente aberto,onde na grande maioria das situações intervêm várias organizações, distribuídas geograficamento,sendo espaços de desenvolvimento de multi-língua e de multi-cultura (organizacional e decostumes); essas adaptações são realizadas a partir do estudo de práticas documentadas e daanálise de entrevistas realizadas a pessoas que desenvolveram DCAP.

A DSR está bem enraízada na literatura; relativamente à taxonomia e teoria podemosmencionar os escritos de Gregor and Jones (2007) e March and Smith (1995); relativamente aosmétodos e processos, os escritos de Peffers et al. (2007) e relativamente a enquadramentos e aguias de utilização, os escritos de Hevner (2007) e de Gregor and Hevner (2013).

O nosso trabalho segue o enquadramento definido por Hevner (2007), enquadramento esseapresentado na secção 3.2.2).

3.2.2 Enquadramento metodológico da Design Science Research: os três ci-clos de Hevner

O processo DSR, de acordo com Hevner (2007), possui três ciclos (ver figura 3.2): RelevanceCycle, Design Cycle e Rigor Cycle. Estes três ciclos actuam em três Espaços:

• Espaço EnvironmentTrata-se do contexto que fornece ao projecto de investigação os requisitos necessários para

2O termo “exaptação” é retirado da Biologia e significa uma adaptação para outras funções.



o desenvolvimento do artefacto, e que define os “critérios de aceitação para a avaliaçãodos resultados do projecto de investigação” (Hevner, 2007, p. 89). Nele actua somente oRelevance Cycle.

• Espaço Design Science ResearchEste é o espaço de desenvolvimento do artefacto, onde o investigador o constrói e o avalia.Os “momentos de avaliação são realizados em laboratório ou em situações experimentais”(Hevner, 2007, pag. 91). Neste espaço intervêm os três ciclos, sendo que o Design Cycle é oúnico que se restringe a este Espaço.

• Espaço Knowledge BaseEsta base de conhecimento fornece os alicerces de trabalho do projecto de investigação,disponibilizando as teorias que explicam ou que suportam os fenómenos e que irão dar rigorao projecto. Por outro lado, o projecto de investigação irá contribuir para o crescimentodo número de teorias na base de conhecimento (extendendo as teorias já existentes ouadicionando novas teorias); irá fornecer novos artefactos, e toda a experiência obtida noprocesso. Neste Espaço actua somente o Rigor Cycle.

Figura 3.2: Os três ciclos definidos por Hevner (2007)

De seguida descrevemos as actividades dos três ciclos referidos e a forma como agem nosespaços descritos.

3.2.2.1 Actividades do Relevance Cycle

As actividades deste ciclo incorporam a “construção” e “avaliação” que March and Smith (1995)referem. Incorporam as actividades de construção na medida em que o investigador procura osrequisitos do espaço Environment para serem incorporados no espaço de DSR no momento dedefinição do artefacto nas actividades do Design Cycle. Por outro lado incorporam as actvidadesde avaliação porque é neste ciclo que o investigador realiza as actividades finais de avaliação doartefacto resultante do projecto de investigação.

A abordagem metodológica para a avaliação depende muito do tipo de artefacto produzido.Ela pode ser feita de duas formas: de forma objectivista ou de forma subjectivista. A abordagem



objectivista parte do princípio que o artefacto pode ser medido, sendo possível definir métricas.Esta abordagem permite utilizar métodos quantitativos de análise. A abordagem subjectivista ébaseada em observações e em suposições. As observações dependem dos observadores e portanto,diferentes observadores de um mesmo fenómeno podem chegar a conclusões diferentes. Noentanto, opiniões diferentes podem ser valiosas para o projecto de investigação por trazeremdiferentes perspectivas para um mesmo problema, enriquecendo as conclusões. Esta abordagemsubjectivista permite utilizar métodos qualitativos de análise Hevner and Chatterjee (2010).

March and Smith (1995) referem que a “avaliação de um método considera a operacionalização(a capacidade de realizar a tarefa definida ou a abilidade de humanos usarem efectivamenteo método), a eficiência, a generalidade (um artefacto funciona num determinado contexto deaplicação mas irá funcionar em todo o universo de contextos?) e a facilidade de utilização” (Marchand Smith, 1995, pag. 261). Tratando-se o nosso artefacto de um método, estamos peranteum artefacto intangível. Neste caso, encontramo-nos no contexto de utilização de abordagenssubjectivistas.

3.2.2.2 Actividades do Design Cycle

Neste ciclo realizam-se as actividades chave de desenvolvimento do artefacto, elas acontecem noEspaço DSR. Nele se realizam micro-ciclos distintos de construção e de avaliação do artefacto,interagindo os micro-ciclos entre si. Ao definir estes micro-ciclos sucessivos vemos que Hevner(2007) integrou no seu enquadramento as actividades cíclicas propostas por Takeda et al. (1990);elas existem para que o investigador possa gerar conhecimento. O processo de DSR “realizamuitas iterações (...) antes de fornecer contribuições ao Relevance Cycle e ao Rigor Cycle” (c.fSecção 3.2.2.3) (Hevner, 2007, pag. 91). Simon (1996), citado por Gregor e Jones (2007), fala deartefactos que evoluem, onde a flexibilidade e a adaptabilidade são activadas através de ciclos defeedback.

O processo de DSR no seu Design Cycle assimila:• a contribuição trazida pelas actividades do Rigor Cycle no Espaço Knowledge Base; esta

contribuição é a selecção da panóplia de conhecimento que existem nas “teorias científicase métodos de engenharia” (Hevner, 2007, pag. 89);

• os requisitos adquiridos no Espaço Environment através das actividades do RelevanceCycle;

e fornece:• ao Espaço Knowledge Base através das actividades do Rigor Cycle (c.f.Secção 3.2.2.3) novos

artefactos e ainda as “experiêncas e expertises que definem o estado da arte no domínio deaplicação” (Hevner, 2007, pag. 89) do processo de DSR.

• ao Espaço Environment o artefacto construído, para uma avaliação final no contexto deaplicação.

As actividades do Design Cycle incorporam, à semelhança do Relevance Cycle, as actividadesde DSR da Design Science “construção” e “avaliação” que March and Smith (1995) referem: é



no Design Cycle que as actividades centrais de desenvolvimento do artefacto são efectuadas, e étambém onde micro-ciclos de avaliação se realizam, dando feedback aos micro-ciclos de construção.Além disso, segundo Vaishnavi (2012), “um grande número de micro-avaliações” acontece em cadadecisão de detalhe da construção. Cada decisão é seguida de uma “experiência de pensamento”onde aquela parte de construção é mentalmente excercitada pelo investigador.

3.2.2.3 Actividades do Rigor Cycle

As actividades deste ciclo identificam as bases de conhecimento (Knowledge Base) necessáriaspara as actividades de construção do artefacto no Design Cycle. Este ciclo realiza ainda asactividades de “teorização” e “justificação” referidas por March and Smith (1995); para isso oinvestigador deverá elaborar as teorias que estão implicitamente contidas no processo de DSR.Este processo vai alimentar o Espaço Knowledge Base de novas teorias.

Na secção 3.3 apresentamos a aplicação específica deste enquadramento metodológico DSRao nosso trabalho.

3.3 Aplicação dos três ciclos de Hevner no caso de investigação

A Figura 3.3 apresenta o resumo da nossa aplicação específica do enquadramento metodológicode Hevner (2007).

Figura 3.3: Esquema da aplicação específica do enquadramento metodológico.

Segundo Hevner (2007) o Espaço Environment fornece o projecto de investigação, através dasactividades do Relevance Cycle, com os requisitos necessários ao seu desenvolvimento e defineainda o contexto de aplicação. No nosso projecto de investigação o contexto de aplicação é acomunidade de metadados. As actividades do Relevance Cycle que fizeram o levantamento dosrequisitos para o desenvolvimento do artefacto (Me4DCAP) são:



• Realização do estudo do estado da arte dos métodos para o desenvolvimento de umPA, estudo este relatado na Secção 2.3. Este é o trabalho que identifica o problema deinvestigação;

• Realização de três entrevistas a pessoas que desenvolveram DCAP (c.f. secção 4.1.2).Ainda no Espaço Environment, o Relevance Cycle realiza actividades de field testing de

validação. Dentro do âmbito deste doutoramento, foram planeadas duas validações:• Um grupo de discussão de validação da V0.1 do Me4DCAP3.• Um FG4 de validação da versão 0.2 do Me4DCAP.

A secção 4.1.3 apresenta em detalhe a validação do nosso trabalho. Sendo o processo de DSRum processo de anos, e que envolve vários investigadores ao longo do tempo Gregor and Hevner(2013), outras actividades de field testing irão ser realizadas em trabalho futuro.

A secção 4.1 apresenta em detalhe as actividades do Espaço Environment.O Espaço Knowledge Base fornece o projecto de investigação, através das actividades do

Rigor Cycle, de :• levantamento da teoria de base onde se sustenta todo o pensamento desenvolvido. No nossocaso apresentamos na secção 2.2 os fundamentos teóricos do nosso projecto;

• trabalho de pesquisa e de estudo dos fundamentos existentes no Knowledge Base dosprocessos, métodos e das técnicas de desenvolvimento de software, centrando este estudonas fases iniciais que vão até à modelação de dados. Este trabalho é relatado na Secção 4.2.1.

No final do projecto de investigação DSR as actividades do Rigor Cycle alimentam o EspaçoKnowledge Base com novo conhecimento, nomeadamente:

• O novo método Me4DCAP - ver Capítulo 5;• “As experiências e o conhecimento que definem o estado da arte do contexto de aplicação do

projecto de investigação”5 (Hevner, 2007, p. 89), no nosso caso a comunidade de metadados.Os artigos publicados representam esse conhecimento e essa experiência.

• As entrevistas realizadas a desenvolvedores DCAP - ver ApÊndice DAlém disso, projectamos, como trabalho futuro, alimentar o Espaço Knowledge Base com as

teorias saídas do processo de “teorização” e de “justificação” já descrito.A secção 4.2 apresenta em detalhe as actividades do Espaço Knowledge Base.O Espaço Design Science Research integra as actividades do ciclo “Design Science”, e recebe

inputs dos ciclos Relevance e Rigor. Nas actividades de construção do Design Cycle o artefacto édesenvolvido. O desenvolvimento do Me4DCAP foi alimentado com (ver Figura 3.4):

• as primeiras fases (até à modelação de dados) através dos métodos de desenvolvimento desoftware;

• os resultados das entrevistas realizadas a pessoas que desenvolveram DCAP;• as práticas identificadas no estado da arte dos métodos para desenvolvimento de perfis de3Ver Curado Malta and Baptista (2013c) - Mais tarde convidados a publicar o artigo na revista Information

Systems & Use - Ver Curado Malta and Baptista (2013a).4Segundo Tremblay et al. (2010) a avaliação do artefacto produzido pela DSR pode ser realizada através da

técnica de FG.5No original: “The experiences and expertise that define the state-of-the-art in the application domain of our

research”.



aplicação de metadados.

Figura 3.4: As três bases de conhecimento para o desenvolvimento do artefacto.

Nas actividades de avaliação do Design Cycle o artefacto é utilizado e avaliado; na realidadeo que acontece nos ciclos de avaliação-construção é que esses ciclos vão depurando o artefactoem desenvolvimento. No nosso caso, utilizámos uma “situação experimental” para realizar osmicro-ciclos de avaliação do artefacto. Esta “situação experimental” foi o desenvolvimento de umDublin Core Application Profile para os Sistemas de Informação Web da comunidade mundial deEconomia Social e Solidária (DCAP-ESS).

A secção 4.3 apresenta em detalhe as actividades do Espaço DSR.

3.4 Sumário

Este capítulo tem como objectivo a apresentação da metodologia de investigação utilizada nonosso projecto de doutoramento. Na primeira secção apresentamos uma pequena resenha sobremétodos quantitativos e qualitativos e as correspondentes técnicas; e identificamos quais dosmétodos e técnicas utilizamos para executar o nosso trabalho. Na secção seguinte apresentamosa fundamentação e o estado da arte da DSR. Iniciamos com a apresentação da definição deDSR, enquadrando-a nas Ciências Naturais e na Design Science. De seguida apresentamos oenquadramento específico por nós utilizado no projecto de doutoramento, os três ciclos de Hevner(2007). Na última secção apresentamos a aplicação específica do enquadramento metodológicoDSR de Henver (2007), onde explicamos de uma forma resumida o trabalho por nós desenvolvidoem cada um dos ciclos definidos por Hevner (2007).


Capítulo 4

Detalhe da aplicação dos três ciclosde Hevner

MATERIALYou must work with your material in order to do anything with it.Touch it, knead it, feel it. Do something and then work with what comesforth. Then true talent, power, and genius will inevitably emerge.

Deng Ming-Dao

Este capítulo tem como objectivo a apresentação detalhada da aplicação dos três ciclos de Hevner(2007) ao caso de investigação. Esta apresentação faz-se através da descrição das actividades pornós realizadas nos três ciclos em cada um dos 3 Espaços identificados por Hevner (2007). Cadaciclo tem um sentido de input, de alimentação de um Espaço, e um sentido de output, devolvendoalgum tipo de informação/conhecimento a outro Espaço. Descrevemos esta dinâmica, começandopelo Espaço Environment, seguindo depois para o Espaço Knowledge Base e terminando no EspaçoDesign Science Research. Este último é onde se constrói o resultado do trabalho de investigação,e onde se desenvolve uma situação experimental. O capítulo termina com a apresentação resumodos trabalhos efectuados na concepção do Me4DCAP. Esta secção tenta revelar a forma comoas actividades se encadeadaram ao longo do tempo.

4.1 Espaço Environment

No Espaço Environment realizam-se as actividades do Relevance Cycle (c.f. Figura 4.1):• Os trabalhos iniciam-se neste Espaço com as actividades do Relevance Cycle que alimentam(seta superior) o Espaço Design Science Research (c.f. secção 4.3). Elas consistem na:

– realização do estudo do Estado da Arte dos métodos para o desenvolvimento de umPA, estudo este relatado na Secção 2.3. Este é o trabalho que identifica o problemade investigação. Os resultados desse estudo, utilizados na construção do Me4DCAP,são apresentados na secção 4.1.1;

– realização de três entrevistas a desenvolvedores DCAP. Os resultados desse estudo,utilizados na construção do Me4DCAP, são apresentados na secção 4.1.2;

45

4. Detalhe da aplicação dos três ciclos de Hevner

• Depois de se realizarem as actividades do Espaço DSR (c.f. secção 4.3), este “exige“ aoEspaço Environment a realização de actividades de validação (c.f. Secção 4.1.3) do artefactopor si produzido. As actividades de validação do Relevance Cycle (seta inferior) são:

– realização de um grupo de discussão (c.f. Secção 4.1.3.1);

– realização de um FG (c.f. Secção 4.1.3.2);

– trabalho futuro de field testing.

Figura 4.1: Esquema da aplicação específica do enquadramento metodológico - Espaço Environ-ment.

4.1.1 Resultados do estudo do estado da arte dos métodos para o desenvol-vimento de um Perfil de Aplicação de metadados

Esta secção apresenta as directrizes importantes encontradas na análise do estado da arte dosmétodos para o desenvolvimento de um PA efectuada na secção 2.3. Apresentamos os resultadosna Tabela 4.1; na primeira coluna ”Item“ estão os documentos onde foram encontrados os pontosregistados na segunda coluna ”O quê“. Nesta segunda coluna estão registados os pontos queachamos importante reter, de forma a integrá-los na definição do Me4DCAP. São práticascomuns utilizadas pelos autores dos documentos indicados. As práticas estão organizadas portópico.



Tabela 4.1: Resultados do estado da arte das metodologias para o desenvolvimento de Perfis deAplicação de metadados

Item O quê

Allinson and Powell (2006) e Eadie (2008) A utilização de grupos de trabalho integrandopessoas de diferentes perfis

de La Passadière and Jarraud (2004) O apoio, no desenvolvimento do PA, de gruposde trabalho que estão inseridos na comunidade aque se destina o PA

Baker et al. (2008),BSI (2005),Chen and Chen (2005),CWA (2006),de La Passadière and Jarraud (2004),Eadie (2008),IMS Global Learning Consortium, Inc. (2005a) A necessidade de uma ”análise de requisitos“, no

entanto não se apresenta em nenhum dos docu-mentos qualquer forma de procedimento para oseu desenvolvimento

Agostinho et al. (2004),BSI (2005),Buonazia and Masci (2007),Chen and Chen (2005),Marzal García-Quismondo et al. (2006),Onyancha et al. (2001),Salokhe et al. (2008) A necessidade da realização de um estado da

arte dos perfis de aplicação e esquemas padrãode metadados. Os documentos ainda referemque um estado da arte pode ser realizado atra-vés: (i) da revisão da literatura (Agostinho et al.(2004), Marzal García-Quismondo et al. (2006));(ii) do estudo de projectos (Buonazia and Masci(2007), Marzal García-Quismondo et al. (2006));(iii) da avaliação de padrões e práticas comuns(Onyancha et al. (2001)).

Agostinho et al. (2004), Marzal García-Quis-mondo et al. (2006)

A necessidade de escolha de um ou mais esque-mas de metadados base, para ponto de partida.

Continua na página seguinte ...



Tabela 4.1 – Continuação

A necessidade de especificação dos elemen-tos de metadados é definida em todos os do-cumentos, na realidade o centro da actividadede desenvolvimento do PA. A forma como essaespecificação deve ser realizada não é referida.Mas há pequenas directizes:

Buonazia and Masci (2007), DCMI (nd), Friesenet al. (2002), IMS Global Learning Consortium,Inc. (2005a),

(i) através da elaboração de cenários ou deconstrução de casos.

Agostinho et al. (2004) (ii) através da aplicação dos elementos do(s) es-quema(s) de metadados base escolhido(s), a umconjunto de recursos. Este trabalho é feito emduas fases:(a) aplicação dos elementos a umaamostra de recursos; (b) resposta a um conjuntode questões

Marzal García-Quismondo et al. (2006) (iii) através da escolha de elementos do(s) es-quema(s) base de: (a) características genéricas;(b) caracterísiticas específicas.

Baker et al. (2008), Onyancha et al. (2001), Eadie(2008)

A necessidade de elaborar um modelo de da-dos é referida em muitos documentos. Esse mo-delo, no caso de Baker et al. (2008), pode serexpresso usando apenas texto ou usando umaabordagem mais formal, como UML; no caso deEadie (2008) é usado o diagrama ER.

CWA (2006) É sugerida uma matriz tendo os elementos demetadados nas linhas e as propriedades dos ele-mentos nas colunas.

4.1.2 Entrevistas a desenvolvedores de Dublin Core Application Profiles

Realizamos três entrevistas a desenvolvedores DCAP (c.f. tabela 4.2):• O plano a que inicialmente nos propusemos foi o de realizar cinco entrevistas Skypesemi-estruturadas às seguintes pessoas que desenvolveram os seguintes DCAP: VMAP;SWAP; TBM-AP; DRYAD; IAP. Estes foram os únicos DCAP identificados no estudorealizado na secção 6.3.1;

• Nem todos as pessoas que desenvolveram DCAP se mostraram disponíveis para umaentrevista. O desenvolvedor do DCAP TBM-AP recusou-se a responder, mesmo por correioelectrónico, com o argumento de que toda a informação estava no site institucional doDCAP, o que não veio a confirmar-se; a desenvolvedora do DCAP IAP nunca respondeuàs várias mensagens de correio electrónico que lhe foram enviadas;



• Os entrevistados receberam um guião (c.f Apêndice D) antes da data acordada para aentrevista. Foi-lhes pedida autorização para a gravação audio da entrevista. As entrevistasforam informais e semi-estruturadas;

• Duas das pessoas que desenvolveram DCAP realizaram a entrevista, e um terceiro respondeupor correio electrónico ao guião (as entrevistas realizadas estão listadas na Tabela 4.2);

• O link http://hdl.handle.net/1822/25805 apresenta um dataset1 contendo o audio eas transcrições das entrevistas.

Tabela 4.2: Lista das entrevistas realizadas a desenvolvedores de Dublin Core Application Profiles.

Nome DCAP Acrónimo Obs.DRYAD DRYAD EmailScholary Works Application Profile SWAP SkypeVariazioni Musical Dublin Core Application VMAP Skype

Seguem-se os resultados das entrevistas.

4.1.2.1 DRYAD

1. Referência à não existência de um método documentado para o desenvolvimento de DCAP;utilizaram a documentação do SWAP.

Looking at SWAP, which was basically the only fully, good documented approachwe could find. Entrevistado DRYAD

2. Referência aos vários perfis necessários na equipe de trabalho: catalogadores de recursos,programadores e especialista do domínio de aplicação:

Information and library science as professional researchers/faculty member(Ph.D.), previous experience as a cataloguer; grad doctoral student with pre-vious experience in-the-field catalogers; doctoral student who had worked as aprogrammer/information architect at a federal institution; 2 master’s studentswho had some experience in cataloging/metadata work, and other library work;NESCent staff members all had a mix of informatics skills and a background inbiology; 2 informatics staff members, one with a MA (biology) the other with aPh.D. (biology) with backgrounds in biology; 1 person with a Ph.D. in computerscience Entrevistado DRYAD

3. Referência à utilização de uma técnica visual para desenhar o modelo de domínio:

just some preliminary diagraming Entrevistado DRYAD

1Disponível em acesso aberto.


http://hdl.handle.net/1822/25805


4.1.2.2 SWAP

1. Não foi utilizado nenhum método de desenvolvimento em particular. Basearam-se emmétodos adquiridos através de práticas de trabalho passadas e de conhecimentos que têm aver com o background do líder dos trabalhos:

This methodology, of we gonna build, so, OK. I think if I were to go back andthink about it I would say that it almost certainly came from common practice atthe time, and so this was probably a lit bit before we did much HL developmentmethodology work. I am right about that. Yeah, so very much before the HLdevelopment methodology, so I think we were at hearing to Team-Member 1 beingfor most sort of software engineering background. I think it very much camefrom this is how one does a formal software engineering process EntrevistadoSWAP

2. Utilização de wiki e de uma mailing list para organização do trabalhos;

There was a... two sets of stakeholders, I think, and one of them was more formalthan the other, but both sets were asked to write to the mailing list and that wasthe end point for them. So they got to discuss on the mailing list but they werenot encouraged to collaborate on the wiki Entrevistado SWAP

3. A equipe de trabalho estava dividida em duas sub-equipes:

(...) but I don’t’ think it came out, it certainly wasn’t something that was part ofa shared collaborative discussion Entrevistado SWAP

There was a... two sets of stakeholders, I think, and one of them was more formalthan the other Entrevistado SWAP

(...) it might have worked as a method of information modelling within that coregroup Entrevistado SWAP

4. A necessidade de envolver os “utilizadores finais” no processo de desenvolvimento do DCAP

Well we didn’t have such end users, we had people who were from the repositoryworld (...), but I think one thing that we were so much short of was pulling justout of an end user view point (...) Entrevistado SWAP

5. Utilização de Casos de Uso para desenvolver os requisitos funcionais:

We had use-cases, in the sense of, people were invited to come out with adescription of why it’s a functional requirement. But the use-case developmentwas not in my memory particularly well informed by any sort of technique. Itwas really a question of we have to develop used-cases, to use-cases... So I thinkthat was very much the story Entrevistado SWAP

6. Justificação da utilização de UML - uma técnica já utilizada no passado:

So there was some, the focus on UML was apparently something of a fortuitousthing, so it seems that they were people involved who had used the UML in thepast Entrevistado SWAP



7. Um grupo mais técnico que utilizou UML nos trabalhos de definição do modelo de domínio.Esse trabalho não foi partilhado com o grupo todo:

To my memory I think there was some fiddling with UML, but I don’t’ think itcame out, it certainly wasn’t something that was part of a shared collaborativediscussion, if it make sense Entrevistado SWAP

8. As técnicas utilizadas, escolhidas pelos líderes dos grupos de trabalho porque as dominam,podem não ser as mais adequadas para o grupo de trabalho. Necessidade de chamar aatenção para esse facto na descrição do Me4DCAP:

Because my feeling is that the level of UML literacy, in terms of this sort ofcomfort of reading it, I think it probably has a high enough barrier that mostpeople simple don’t actually bother, in this domain, I mean, another domaincertainly they do Entrevistado SWAP

9. O modelo de domínio estava desde o início agarrado a um modelo conceptual (FRBR):

Kind of 80% of the answer to that is that they already knew what answer theywanted, in my personal opinion, because they collected requirements as I say, butthen they turn around and said yes, but we are basing this on FRBR, now, soFRBR already is their data model Entrevistado SWAP

10. É muito importante que a fase de validação em produção esteja integrada nos trabalhos dedesenvolvimento do DCAP:

(...) but the issue became clearer when that got to interface development anduser level implementation, so I would argue that user implementation, user levelimplementation is absolutely something that should be part of that developmentprocess, that really we needed to take, to test that, while long before we said, ohthis is a standard Entrevistado SWAP

11. Referência para a importância da validação em laboratório (em papel) e do carácterprofundamente iterativo que o processo pode tomar:

It’s all right to try five things specially if you can try them on paper, you know,and see which one looks most promising, or see which two look much promisingand build one and see which one you like best Entrevistado SWAP

4.1.2.3 VMAP

1. Confirmação de que não há de facto método para o desenvolvimento de um DCAP:

(...) pues quería responder un poco y realmente “hay alguna metodología paradesarollar DCAP? No, solamente hay un documento y que da muy poco so-porte, te hicieron documentos que piden que hay que escribir, no hay nada (...)Entrevistado VMAP

2. A equipe de trabalho do VMAP integrou pessoas que eram especialistas no campo deaplicação:



Eran músicos, analistas musicales, gente que se dedica a catalogar música En-trevistado VMAP

3. Mas que não tinham formação em catalogação nem em tecnologias de WS e isso foi umproblema grave:

Pero los que lo hacían no tenían tan poco la formación adecuada. Persona X yono se que formaciones tiene, pero yo sospecho que es . . . . cantante y tal, pero notiene ninguna formación en catalogación, ni tampoco in tecnologías semánticas yles hablas disto y les suena como a chino Entrevistado VMAP

4. Os modelo de domínio teve como base o esquema de base de dados já existentes dos váriosparceiros, e os recursos já existentes:

La basis fu que queríamos catalogar en nuestro caso y el dominio era los, como sellama?, los, las bibliotecas musicales o las colecciones musicales que teníamos quecatalogar, entonces teníamos que catalogar material multimedia, vídeos, materialescrito que había scaneado, cartas de autores cosas así y programas y tal y logoaudio, que había también grabaciones de conciertos y cosas así (...) pero lo queson las entidades reales venían de las colecciones Entrevistado VMAP

5. Alguns documentos já tinham sido elaborados antes do início do projecto, herdaramdocumentos realizados fora do core da equipe de trabalho:

Porque sabes nos ya teníamos un documento de requisitos en el proyecto y yalo tenemos escrito, logo al final cuando ya seguimos . . . e tenemos el primerdocumento requisito pero no siguiendo el formato de DCAP, no! Pero claro quecuando se recogieran los metadatos era para ver los requisitos del proyecto everificar sus dibujos Entrevistado VMAP

6. Referência a um processo de validação iterativo:

Catalogábamos obras e de allí veíamos se los que estaban catalogando parecía claroo no claro los nuevos metadatos e básicamente fue así, catalogar bastantes obrasde forma manual y con varias iteraciones, pues se tuve viendo que metadatos lagente usaba, que es lo que no usaba, ver o que proponíamos, luego muchas veces,pues los que catalogan pues no lo usan no? Entrevistado VMAP

7. Referência a realização de prototipagem no mesmo momento que se fazia a validação.Será interessante estudar os processos ágeis e entender como esses processos poderão serintegrados numa versão futura do Me4DCAP.

No remodelarlo solo en papel si no que hicimos para cada cosa que hacíamostenemos un prototipo. Catalogamos obras e de allí veíamos se los que estabancatalogando parecía claro o no claro (...) Entrevistado VMAP

8. Referência ao facto de haver micro-equipes por organização parceira para realizar a validaçãodos seus próprios recursos:



La escuela era del Porto (...), pero (...) catalogaron con sus obras. EntrevistadoVMAP

4.1.3 Validação do Método para o Desenvolvimento de Dublin Core Appli-cation Profiles

Depois de construído o artefacto, o processo de DSR exige que o Relevance Cycle realizeactividades de validação no Espaço Environment:

• A secção 4.1.3.1 apresenta o grupo de discussão realizado na conferência ElPub2013. Osresultados deste grupo de discussão, juntamente com os outputs da discussão gerada apartir da apresentação do artigo na conferência, alimentaram a V0.2 do Me4DCAP;

• A secção 4.1.3.2 apresenta o FG realizado na conferência DC-2013. Os resultados do FGalimentaram a V1.0 do Me4DCAP, resultado final deste projecto de doutoramento.

4.1.3.1 Grupo de discussão - ElPub 2013

Este grupo de discussão foi realizado na conferência ElPub20132. O grupo de discussão foiuma sessão aberta3, integrado no programa da conferência, em simultâneo com outra sessão.Foi enviado um email no dia anterior à sessão (c.f. Secção F.3) a todos os participantes daconferência no sentido de apelar à sua participação.

Esta validação foi efectuada à V0.1 do Me4DCAP - c.f. Curado Malta & Baptista (2013b).O Apêndice F apresenta a transcrição da sessão.

De seguida apresentamos os pontos que retiramos da discussão:• Em “In fact, recent studies show that there is no formal method to develop a DCAP”(Curado Malta and Baptista, 2013b, pag. 34), retirar a palavra ”formal“ do texto.

• Apesar de o método já ter em conta o facto de um DCAP ser um constructo cujo de-senvolvimento é realizado por grupos muito heterogeneos, distribuídos geograficamente,podendo pertencer a várias organizações (ao contrário do desenvolvimento de um softwarecujo desenvolvimento é normalmente efectuado dentro de uma organização), num ambientetotalmente aberto, é importante referir isso no texto do método e reflectir um pouco maissobre de que forma estas características particulares têm impacto na construção do DCAP.

• Retirar a exigência de utilização da técnica UML na representação do modelo de domínio.

4.1.3.2 Focus Group - especialistas de metadados

Este FG foi realizado com especialistas de metadados4. Esta validação foi efectuada à V0.2 doMe4DCAP - c.f. Curado Malta & Baptista (2013c). O Apêndice G apresenta a descrição do FG.

217th International Conference on Electronic Publishing, na Suécia (Kalskrona), nas instalações da BlekingeInstitute of Technology a 13 e 14 Junho 2013.

3Ver http://www.bth.se/com/elpub2013.nsf/pages/special-session-me4dcap-v014Aproveitando a presença destes especialistas na conferência DC-2013, em Lisboa, Portugal, de 2 a 6 de

Setembro de 2013.


http://www.bth.se/com/elpub2013.nsf/pages/special-session-me4dcap-v01


Participaram sete pessoas com as características socio-demográficas e escolares referidas naTabela 4.3. A média de idades foi de 56 anos e com clara predominância para participantes dosexo masculino.

Tabela 4.3: Características socio-demográficas e escolares dos participantes do FG.

Participante Idade Gén. Grau Académico Área CientíficaA 62 M Mestrado Ciências da InformaçãoB 63 M Mestrado Computação em Ciências da In-

formaçãoC 59 M Mestrado –D 55 M Doutoramento Ciências da InformaçãoE 40 F Doutoramento Ciências da Informação - Biblio-

tecas (LIS)F 60 M Doutoramento Bibliotecas digitaisG 52 M Mestrado Investigação em Metadados Bibli-

ográficos

Apresentamos, na Tabela 4.4, uma síntese das características profissionais dos participantesque legitimam a importância da sua participação para a validação do Me4DCAP5.

O que apresentamos a seguir é uma análise comentada do FG com os resultados principais.A itálico está o que foi verbalizado na sessão pelos participantes, seguido dos nossos comentáriossobre o tópico discutido ao que será alterado na V1.0 do Me4DCAP, ou sobre o que não seráalterado, apesar dos comentários, e a justificação de tal facto.

Comentários Gerais1. O Me4DCAP assume que a equipe de trabalho começa o processo a partir do zero. No

entanto num processo de desenvolvimento de um DCAP nunca se começa a partir do nada,há sempre trabalho já feito (ex: uma base de dados com um modelo de dados).

• Definir outros pontos de entrada no processo, e não somente no bloco 1.2. O Me4DCAP deverá ser um processo flexível - poderá pensar-se em deixar cair determinadas

actividades em determinados momentos, deverá permitir acrescentar nova informação comfacilidade (extensível)

• Tornar explicito no método que os únicos deliverables obrigatórios são os que sãoobrigatórios no Enquadramento de Singapura. Em relação a todos os outros, érecomendado o seu desenvolvimento mas não obrigatório; eles existem para ajudar adesenvolver os que são obrigatórios. Dependendo do tipo de problema, a equipe detrabalho pode decidir quais as actividades a realizar de forma a desenvolver ou nãodeterminado tipo de deliverables.

3. O Me4DCAP deverá ser escalável.• Irá ser estudado em trabalho futuro a possibilidade de o tornar mais escalável.

5Foi mantido o que os participantes escreveram em inglês, sem tradução nem qualquer alteração.



4. Os Singapore Stages são processos porque se trata de seguir um caminho produzindodeliverables ao longo do tempo. Estes processos resultam no final também num deliverable.Seria importante expressar isso desta forma.

5. Usar nomes para os deliverables e verbos para os processo. Por exemplo o “Relatório devalidação” é o resultado de um processo de verificação. E não como está “To check”.

6. As setas podem ser expressos como verbos e os nodos como nomes.

• Reorganizar o esquema apresentado (Fig.3 de Curado Malta e Baptista (2013d) ).O caminho entre cada deliverable deverá ser identificado com o processo que lhe dáorigem, utilizando nomes para os deliverables e verbos para os processos.

Equipa de Trabalho1. É necessário discutir melhor o que se entende por “utilizador final de um DCAP”. Um dos

membros do grupo de trabalho acenou vivamente com a cabeça, concordando, mas não deuqualquer opinião. Referiu-se que era o stakehoders, outros concordaram. Referiu-se aindaque poderia ser: (i) alguém que usasse o sistema; (ii) alguém que alimenta o sistema; (iii)alguém que faz a programação do sistema. Em suma que poderia haver todo um conjunto detipos de pessoas que poderiam ser chamadas de “utilizador final”. Resumiu-se dizendo quepoderão chamar-se target users. No final concordou-se de que o termo seria stakehoders,havendo vários tipos de stakeholders.

• Referir que há vários tipos de utilizadores potenciais que podem ser, por exemplo osprogramadores das aplicações que vão fazer uso do DCAP, as pessoas que alimentamo sistema, as pessoas que consomem informação do sistema, etc.

2. É necessário incluir uma pessoa especialista no campo de actuação do DCAP.• Incluir um perfil de especialista da área de aplicação (isto já está coberto pelo perfil“Gestor de projecto”, mas iremos definir explicitamente esse perfil).

3. Deveria incluir-se/designar-se na equipe de trabalho o tipo de papel “Editor”: o(s) ele-mento(s) que irão contruir os documentos. Não caso de ser uma equipe de trabalho pequena(<6 elementos) pode-se assumir que todos sejam editores; no caso de ser grande umaequipe grande fará sentido designar editores que serão única e exclusivamente responsáveispela produção de documentação do DCAP. Este perfil deverá designar-se por “Editor” ou“Editor técnico”; deverá possuir competências em escrita técnica e ainda ter conhecimentoda área de actuação do DCAP.

• Incuir o perfil de “Editor Técnico”. Este perfil será responsável pela elaboração detoda a documentação. À semelhança de todos os outros perfis, este perfil pode serpartihado por várias pessoas.

4. Relativamente à dimensão da equipe de trabalho deverá referir-se no Me4DCAP que éaconselhável que seja um grupo entre 6 e 12 elementos. Estes são os valores óptimos parase realizar um trabalho eficiente.

5. O trabalho é essencialmente técnico, e por isso pode-se definir uma equipe central - Coreteam - a que se poderá juntar, à medida das necessidades, pessoas que façam determinadas



partes específicas do trabalho. Poderá haver um conjunto de stakeholders que irão realizandoa validação ao longo do processo. Outra pessoa, reforçando e reformulando melhor o quevinha sendo dito, disse que poderia haver a equipe central (core team), composta pelosmembros técnicos, e a equipe extendida (extended team), que seria composta por stakeholderse especialistas da área de actuação do DCAP, que seriam consultados sempre que fossenecessário fazer uma validação dos trabalhos efectuados.

• Para equipes maiores (> 6 pessoas) deve sugerir-se que a equipe pode ser composta poruma “Equipe Técnica” e por uma “Equipa Alargada”. A Equipe Técnica é compostapor stakeholders com conhecimentos técnicos. A Equipe Alargada é composta porstakeholders com conhecimento não técnicos (por exemplo especialista do domínio deaplicação, gestor de projecto, etc.).

Ciclo de Vida1. Propõe-se a alteração do gráfico que apresenta o ciclo de vida. Achou-se muito rígido e

pouco flexível.2. Um membro do grupo de trabalho desenhou no quadro (ver Figura 4.2) o que poderia ser a

nova forma, em relógio. Os nodos representam os deliverables.• Mudar a representação gráfica de modo a: (1) remover complexidade; (2) adicionar

flexibilidade; e (3) melhorar a aparência

Figura 4.2: Esboço proposto por um dos participantes

Documento Visão1. Pode ser algo que é feito antes de que o processo de desenvolvimento do DCAP comece,

definido por responsaveis do(s) departamento(s) da(s) Organizações interessadas no processo.Mas pode ser também feito logo no início do processo, pela equipe de trabalho.

2. A decisão de construir um DCAP pode também vir de fora da equipe de trabalho, e a Visão



será a forma de a equipe definir a sua expressão do trabalho a ser realizado. De forma anão ser algo imposto mas sim algo que foi definido como um compromisso de toda a equipe.

• Não é necessariamente o primeiro trabalho a realizar pela equipe uma vez que a “Visão“pode ter sido feita e entregue à equipe de trabalho por parte da gestão da equipe.


4.Detalhe

daaplicação

dostrês

ciclosde

HevnerTabela 4.4: Características profissionais dos participantes do Focus Group.

Part. Profissão Expertise Projectos

AFounder and Principal consul-tant of taxonomies strategies.Develop vocabulary require-ments and specifications for or-ganisations

Library Science; Information Science; In-formation Management; Management Sci-ence

Many projects for governmental and commercial or-ganisations - applied research; Dublin Core board ofdirectors; Program manager for standards and researchprojects at Getty foundation

B Consultant in National Li-brary Board in Singapore

Information Technology; Management; Di-gital Infrastructure; Digital Preservationand metadata

DC; PREMIS; EAD

C Consultant Egovernment; Cultural Heritage DCMI; DCAT Application Profile; ADMS; EuropeanaData Model

D Chief Information Office; Du-blin Core Metadata Initiative;Consultant

Semantic Web, Metadata, Information Mo-dels; Sociologist; PhD Antropology

Chair DCMI Usage board (standards); Co-chair W3CSemantic Web deployment working Group (standards);Consultant Metadata (e.g. Journal of Web Semantics)

E Associate Professor of Libraryand Information Sciences, nowteaching the courses of: In-formation Skills, vocabulariesfor the Semantic Web and So-cial Web. Currently DeputyVice-rector of Infrastructuesand Environment focused inLibrary and IT Services of theUniversity

Metadata; Digital Libraries; InformationPolicies; Semantic Web Technologies; So-cial Web

PhD Thesis - Metadata; Several R&D projects relatedwith the fields of Geospatial Information, LOD, Edu-cational repositories, Open Access & DLS in general

F Professor at an InformationSchool in Japan; major rese-arch topics are metadata, digi-tal archives and presentation

Medadata; Digital Archives; background inSoftware Engineering, Programming Lan-guages

Metadata schema registries; Metadata Models; ReuseTechnology for metadata; Metadata for comics

G Consulting project manager(OCLC research): (i) provideproject management supportfor OCLC research projects;(ii) serve as research projectream member on metadata re-lated projects

Controlled Vocabularies, Metadata stan-dards; Metadata Systems; Metadata Ap-plications

Library Cataloger; expert in audiovisual library cata-loging (chair of ALA AV committee; invited to leadPCC AV CORE TG by Library of Congress); Memberof FAST (Faceted Application of Subject Terminology)team; member of VIAF team; Member of Dublin CoreAdvisory Board

58Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica


• No caso do esforço de desenvolvimento do DCAP ser partilhado por várias organizações,há uma grande probabilidade de que a ”Visão” seja definida pela equipe de trabalhode desenvolvimento do DCAP

• Definir outros pontos de entrada no processo, e não somente no bloco 1

Expressão dos requisitos funcionais1. Pode confundir-se este artefacto com o artefacto “Requisitos Funcionais” pelo que se propõe

uma mudança de nome para “Requisitos Gerais” (General Requirements), “Requisitos de altonível” (High-Level Requirements) ou ainda “Requisitos do Projecto” (Project Requirements)

2. Não necessariamente “requisitos funcionais”, podem ser só “requisitos”.3. Dois níveis distintos: este artefacto expressa os requisitos do projecto; o artefacto “Re-

quisitos Funcionais” expressa os requisitos funcionais do DCAP. Deve retirar-se o termo“Funcionais” do nome deste artefacto.

• Mudar o nome para “Requisitos de alto nível” (High Level Requirements) para incluirrequisitos não-funcionais.

• Ideia para reflexão: não é fácil usar os Métodos Ágeis quando temos somente requisitosfuncionais de alto nível. O mesmo modelo de domínio pode ser adequado paraaplicações muito diferentes que têm os mesmos requisitos funcionais de alto nível. Emmuitos casos, a miríade de aplicações diferentes não pode ser totalmente prevista paraaqueles que estão a conceber um DCAP naquele momento específico. Por exemplo:o DCAP SWAP pode originar muitas aplicações diferentes - como podem então osprotótipos ser desenvolvidos e testados nos Métodos Ágeis?

Modelo de Casos de Uso1. Os Casos-de-Uso podem ser expressos somente em palavras, não necessariamente através

de formas gráficas.2. Não ser tão directivo, as pessoas podem ter a liberdade de encontrar a sua forma de

representar Casos-de-Uso e não obrigar a nenhuma forma em especial.• Não serão feitas quaisquer modificações. Uma representação gráfica dos casos de usoé essencial para entender rapidamente o que está em jogo

Requisitos Funcionais1. É necessário uma forma de verificar se todos os Casos-deUso cobrem todos os requisitos

funcionais definidos. Tem de ser definido um critério de êxito.• Referir a necessidade de fazer um cross-check de Requisitos Funcionais e Modelo deCasos-de -Uso.

2. Definir o que o sistema “deve” fazer e o que o sistema “pode” fazer (What the system “mustdo” and what the system “can do”). Requisitos prioritários e requisitos não prioritários.

• Referir no momento da definição dos “Requisitos de alto nível” que é necessário forneceruma forma de distinguir os requisitos funcionais e casos-de-uso mais importantes.



Modelo de Domínio1. Não obrigar a utilizar nenhuma técnica em particular.

• Sugerir técnicas (por exemplo ORM, UML, E-R, RDF) informando o leitor que deveescolher a técnica que melhor sirva a equipe. É importante chamar a atenção para ofacto de poder haver uma tendência do líder do grupo para decidir pelo grupo por sera técnica que melhor controla, mas essa técnica pode não ser a que o grupo como umtodo melhor domina.

2. A que ponto é o modelo extensível? Isto é, a que ponto se poderá encaixar nova informaçãono modelo. É importante ter alguma visão da “extensibilidade” do modelo.

• Alertar o leitor para a questão da necessidade de pensar a extensibilidade do modelo.

Dossier de Integração1. O nome é demasiado complexo e pomposo para o que é. Sugere-se uma alteração de nome.

• Mudar nome para: “Pré-DSP”.2. Diagrama ORM de Dados Detalhado:

(a) Trata-se da “decoração“ do Modelo de Domínio. Aos objectos juntar as propriedades.(b) Utilizar a técnica UML.(c) Deverá representar-se através de um diagrama, mas a técnica escolhida para o expressar

deverá ser deixada ao critério do desenvolvedor.• Mudar o nome para: “Modelo de Dados Detalhado”.• Sugerir técnicas (por exemplo Object Role Modeling (ORM), UML, ER, triplosRDF) informando o leitor que deve escolher a técnica que melhor sirva a equipe.É importante chamar a atenção para o facto de poder haver uma tendência dolider do grupo para decidir pelo grupo por ser a técnica que melhor controla, masessa técnica pode não ser a que o grupo como um todo melhor domina.

3. Relatório do Estado da Arte(a) Este deliverable será divido em dois: o deliverable “Environmental Scan” e o deliverable

“Alinhamento de Vocabulários” (Vocabulary Alignment). O “Environmental Scan”deverá começar a ser desenvolvido logo após a definição dos ”Requisitos de alto nível“.O ”Alinhamento de Vocabulários” é o que aqui se chama de “Relatório do Estado daArte”.

4. Documento de Integração(a) Mudar o nome para “Matriz de restrições” (Constraints matrix) ou “Especificação das

restrições” (Constraints specification).• Mudar o nome para: “Matriz de Restrições”.

Dossier de Validação1. Mudar nome para: “Validação em Laboratório”.2. Relatório de Validação

(a) Propos-se uma mudança de nome para “Verificação de Validação” (Assessement Check)



ou “Verificação de Adequação” (Adequacy check)• Mudar o nome para: “Teste de Adequação“.

(b) Na expressão “DCAP adequacy” - o que significa “adequacy”? Definir o seu significadoe definir parâmetros para entender quando se pode falar de adequação do DCAP.

(c) Tomar decisões acerca de coisas subjectivas não é fácil. Devem definir-se os critériosno momento da definição dos “Requisitos Funcionais”.

• Definir um novo deliverable chamado ”Critérios de Adequação“, que deve serelaborado depois da finalização dos ”Requisitos Funcionais“. Este novo deliverabledeverá definir os critérios de adequação do DCAP, definindo quais as formas quea equipe de trabalho encontra para que se verifique que o DCAP suporte todasas funcionalidades obrigatórias.

3. Documento de Validação

(a) Mudar o nome para “Teste de Avaliação” (Assessement Test) ou “Teste de Adequação”(Adequacy test) ou “Documento de Aceitação” (Acceptance document).

• Mudar o nome para: ”Teste em Laboratório“.

(b) Referiu-se como sendo um exercício “Let’s try and use it”

• Deveria ficar claro no texto de definição do Me4DCAP que este deliverable é umainstanciação do DCAP.

4. Questionário(a) Importante para obter feedback.(b) Neste documento podem definir-se os critérios de adequação.

• Referir no texto que os resultados do Questionário podem obrigar a uma iteraçãode forma a rever o ”Modelo de Domínio“ ou os ”Requisitos Funcionais“. Aabordagem iterativa está presente em todos os momentos do desenvolvimendomas é nesta fase de ”Validaçao no Laboratório“ que ela poderá tornar-se maisintensa.

Guias

1. No “Documento de integração” deverá acrescentar-se uma coluna de nome “Nota de Uso”(Usage Note) onde já se começa a preparar o “Guia de Utilização”. A ideia é anotarquestões particulares nas propriedades, se se reutilizam propriedades, etc.. Começando adocumentar no imediato o que se pretende de cada propriedade.

• Adicionar uma coluna “Nota de Utilização” à “Matriz de Restrições”.

Validação em Produção1. Introduz-se a ideia de validar ao longo do processo de desenvolvimento e não somente no

final, processo inspirado nos processos Ágeis (Agile processes) - ao longo do processo dedesevolvimento ir-se libertando pequenos blocos de software para testar as funcionalidades



até ali desenvolvidas. Como obter um modelo semelhante num processo de desenvolvimentode um DCAP?

2. A validação em produção não é um requisito. Está fora do âmbito da definição do processode desenvolvimento de um DCAP.

3. Deixar um comentário dizendo que se pode fazer (porque por exemplo é bom ver se há bugs)mas que está fora do âmbito.

4. Também se poderia pensar em introduzir algo sobre a manutenção do DCAP, mas foiunânime que isso também está fora do âmbito do Me4DCAP.

• Referir que se trata de uma fase opcional• A exploração dos Métodos Ágeis será realizada em trabalho futuro.

4.2 Espaço Knowlegde Base

No Espaço Knowledge Base realizam-se as actividades do Rigor Cycle (c.f. Figura 4.3):

Figura 4.3: Esquema da aplicação específica do enquadramento metodológico - Espaço KnowledgeBase

• Os trabalhos iniciam-se neste Espaço com as actividades do Rigor Cycle que alimentam(seta superior) o Espaço DSR (c.f. secção 4.3). Estas actividades realizam-se a par dasactividades do Relevance Cycle descritas no Espaço Environment (c.f. 4.1) que alimentamtambém o Espaço DSR. Estas actividades do Rigor Cycle consistem no:– levantamento dos fundamentos teóricos que sustentam as reflexões e as teorias desen-

volvidas no nosso caso de investigação. Esse trabalho foi apresentado no secção 2.2;– levantamento dos métodos ou processos de desenvolvimento de software que integras-

sem nas suas primeiras fases modelação de dados; no levantamento das teorias sobreciclos de vida de software; no levantamento de técnicas de modelação de dados. Estetrabalho é apresentado na secção 4.2.1.



• Depois de se realizarem as actividades do Espaço DSR (c.f. secção 4.3), este alimenta oEspaço Knowledge Base através das actividades do Rigor Cycle (seta inferior):– com novo conhecimento, na forma de um novo método, o Me4DCAP - apresentado

no capítulo 5;– com novo conhecimento na forma dos artigos publicados: Curado Malta and Baptista(2012a), Curado Malta and Baptista (2012b), Curado Malta and Baptista (2013a),Curado Malta and Baptista (2013b), Curado Malta and Baptista (2013c), CuradoMalta and Baptista (2013d), Curado Malta and Baptista (2014), Curado Malta et al.(2014).

– com novo conhecimento através dos registos das entrevistas aos desenvolvedoresDCAP. Os ficheiros audio e transcrições em pdf estão disponíveis em acesso abertono Repositório da Universidade do Minho no URL http://hdl.handle.net/1822/

25805;– fornecerá ainda, após realizado o trabalho futuro projectado para finalizar o processo

de DSR, as novas teorias que sairão do processo de teorização e justificação.

4.2.1 Análise dos métodos para o desenvolvimento de software

4.2.1.1 Introdução

Reflectimos no sentido de encontrar um ponto de partida para a construção do método. Oconstructo DCAP traduz um modelo de dados, por essa razão fará sentido procurar métodosde desenvolvimento de sistemas que incorporem no seu processo o desenvolvimento de modelosde dados. Sabemos que os processos de desenvolvimento de software incorporam uma taldimensão nas suas primeiras etapas de desenvolvimento. Contudo, um DCAP não é um sistemade informação nem um software, e a quantidade de DCAP desenvolvidos na comunidade demetadados é bastante inferior à quantidade de software desenvolvido em todo o mundo. Sabemosque o desenvolvimento de software se tornou numa actividade tão intensa que houve a necessidadede criar uma área de estudos de métodos para o desenvolvimento de sistemas de informação:a Engenharia dos Métodos6. Poderíamos, por isso, ter definido o nosso ponto de partida apartir de teorias da engenharia dos métodos. Contudo, tendo um DCAP, na sua construção,momentos de desenvolvimento semelhantes aos do desenvolvimento de um software, o nosso pontode partida é o da Engenharia de Software. Este trabalho de doutoramento enquadra-se tambémnum departamento de engenharia com saber-fazer de investigação na área de desenvolvimentode software7; e a nossa formação é também precisamente nessa área, pelo que é coerente partirdesta perspectiva. Assumimos que o nosso trabalho tem um bias de engenharia de software, erespeitamos a possível existência de outras influências num trabalho futuro de melhoramento.

A secção seguinte apresenta a análise dos métodos para o desenvolvimento de software.

6“A Engenharia dos Métodos é a disciplina de engenharia que concebe, constrói e adapta métodos, técnicas eferramentas para o desenvolvimento de sistemas de informação” (Brinkkemper, 1996, p. 276).

7Ver http://semag.algoritmi.uminho.pt - acedido em 9 de Dezembro de 2013.




http://semag.algoritmi.uminho.pt


4.2.1.2 Estratégias de pesquisa

Foram efectuadas pesquisas bibliográficas com pesquisas gerais e depois refinadas nas bases dedados on-line. As bases de dados utilizadas foram o Google Scholar8, o ISI Web of Knowledge9,o SCI ETD Networked Digital Library of Thesis and Dissertations10, o Scopus11 e o Oaister12.

Na primeira fase das pesquisas foram realizadas pesquisas utilizando os termos chave: softwaremethods, software process, software methodologies, data modeling techniques. As pesquisas foramrealizadas no campo “título do artigo”, no campo “assunto” e no campo “corpo do artigo”. Numafase posterior foram pesquisados artigos a partir do nome dos autores relevantes identificados atéà data.

Os artigos foram seleccionados seguindo o critério de “relevância do título”, “número decitações” e de qualidade da “revista científica” (com um factor de impacto JCR/SJR maiselevado).



4.2.1.3 Resultados

Todo o processo de desenvolvimento de software inclui à cabeça, no seu ciclo de vida, um conjuntode actividades de especificação de requisitos e de desenho. Estas actividades são depois seguidasde outras, de implementação, de teste e de manutenção Nijssen and Halpin (1989).

Existem três tipos diferentes de ciclos de vida de desenvolvimento de software (existem outrosmas que vão, na sua matriz, beber a um destes três), respondendo às necessidades dos tempos edos contextos de aplicação:

O modelo em cascata (Waterfall)modelo tradicional na engenharia de software - foi introduzido por Royce (1970) e maistarde refinado por Boehm (1976) Davis et al. (1988). Neste ciclo de vida as fases seguem-seconsecutivamente, uma seguinte à outra, para transitar de uma fase à outra é necessárioterminar a anterior.

O modelo iterativo e incremental McCracken and Jackson (1982)aparece para colmatar os problemas que o modelo anterior trazia, pela necessidade da

8http://scholar.google.com - acedido em Outubro de 2012.9http://www.isiWebofknowledge.com - acedido em Outubro 2012.

10http://www.ndltd.org/serviceproviders/scirus-etd-search - acedido em Outubro 2012.11http://www.scopus.com - acedido em Outubro 2012.12http://oaister.worldcat.org - acedido em Outubro 2012.








definição de toda a documentação nas fases iniciais de definição de requisitos, antes dapassagem para as fases seguintes Boehm (1988). Este modelo é ”o processo de construiruma implementação parcial de um sistema e lentamente ir adicionando funcionalidadecrescente ou performance.’ (Boehm, 1988, p. 1454).

O modelo evolutivo e adaptativo Larman (2004)tem como “comportamento o crescimento à medida das necessidades. Este modelo permitea modificação, adição, e remoção de definições no sistema a qualquer momento” (Fernán-dez-López et al., 1997, p. 35) do processo. Este ciclo de vida implica que os requisitosevoluem, ou são refinados ao longo das iterações, em vez de ficarem definidos ou congeladosnum momento inicial de especificações Larman (2004).

Em 2001, um conjunto de individualidades lançou o “Manifesto para o DesenvolvimentoÁgil de Software” (c.f. Beck et al. (2001)) que apresentou uma abordagem conhecida como “osprocessos ágeis de desenvolvimento de software”. Reuniu representantes de Extreme ProgrammingBeck (2005), SCRUM Cohn (2009), Dynamic Systems Development Method DSDM Consortium(2013), Adaptive Software Development Highsmith (2004), e outros, em torno da necessidade deencontrar alternativas para processos de desenvolvimento de software que fossem complexos. Odesenvolvimento ágil oferece a oportunidade de avaliar a orientação de um projecto durante todoo seu ciclo de desenvolvimento, uma vez que potencia a obtenção de respostas rápidas e flexíveisface às mudanças nos requisitos do projecto. Os processos ágeis estão intrinsecamente ligados aociclo de vida evolutivo e adaptativo.Todos os ciclos de vida referidos incluem as fases de elicitação de requisitos e de desenho, comojá mencionado. O desenho deverá ir de encontro aos requisitos levantados: trata-se de analisara área de aplicação ou Universo de Descoberta (UdD) e retirar a informação necessária paraa descrever. Esta descrição é a modelação de dados, de uma forma mais ou menos complexa,mais ou menos aprofundada, dependendo do contexto e das necessidades da fase seguinte, aimplementação. Essa modelação de dados é feita através de técnicas específicas de modelação dedados, e descreve a estrutura do UdD numa “linguagem” que possa ser entendida pelos váriosinterveninentes no processo.

Nas nossas pesquisas encontrámos dois tipos diferenciados - pelo tipo de objecto de softwaredesenvolvido - de métodos da engenharia do software com partes do processo onde estão presentesas práticas de elicitação de requisitos e modelação de dados:

• métodos de desenvolvimento de aplicações hipermédia ou de sítios Web;• métodos de desenvolvimento de software.Os resultados são apresentados nas sub-secções seguintes.

4.2.1.3.1 Métodos de desenvolvimento de aplicações hipermedia, de sítios ou sis-tema de informação WebRelationship Management MethodologyÉ um método para desenvolver sítios Web em geral, mas mais especificamente SIW e do tipo



quiosque13. O ciclo de vida do Relationship Management Methodology (RMM) é composto portrês fases: desenho, desenvolvimento e construção. A fase de desenho é totalmente baseadano modelo Relationship Management Data Model (RMDM), este modelo baseia-se por sua veznum outro modelo, o HDM e no seu sucessor HDM2 (c.f. Garzotto et al. (1993)), ele introduzelementos para definir o desenho de hipermédia e sua metodologia, nos quais os seus antecessoreseram omissos. O RDMD apresenta primitivas que servem para definir a estrutra do domínio deaplicação (primitivas ER) Chen (1976), primitivas para apresentar a forma como a informação éapresentada (modelo de fatias) e finalmente primitivas de acesso para apresentar o modelo denavegação).

A fase de desenho é composta por três sub-fases:1. S1: Desenho ER com a produção do artefacto ER;2. S2: Desenho de entidades com a produção do artefacto ER extendido;3. S3: Desenho de navegação com a produção do artefacto diagrama Relationship Management.Em qualquer uma destas três sub-fases existe a possibilidade de realimentação dos artefactos

previamente elaborados. A sub-fase S1 tem como objectivo representar o UdD da aplicaçãoatravés de um ER. A sub-fase S2 tem como objectivo definir como as entidades definidas nafase anterior serão apresentadas aos utilizadores e como eles podem aceder a essa informação. Asub-fase S3 tem como objectivo o desenho dos caminhos de navegação a partir do ER extendidoproduzido na fase anterior.

Comentários: Este método apresenta-nos um ciclo de vida iterativo, o que nos parece sermuito interessante para este tipo de contexto onde há grande dificuldade em definir o UdD.

The Web Site Design ModelÉ um método para a concepção de sítios Web do tipo quiosque, tipicamente centrado no utilizador.Um sítio Web do tipo quiosque é um sistema aberto, na Web, onde qualquer pessoa é um potencialutilizador. Este método possui uma fase de “modelação dos utilizadores”, seguida de uma fasede “desenho conceptual”, seguida de uma de “implementação do desenho”, seguida de uma fasefinal de “implementação”. As duas primeiras fases são as que nos interessam particularmente.

Na fase de “modelação dos utilizadores” interessa antecipar as questões dos potenciaisutilizadores e reponder a essas questões, para poder identificar os potenciais utilizadores. Paraisso, deve construir-se uma “declaração da missão” do sítio Web. Depois disso, cada organizaçãoou processo é dividido em actividades. Como cada actividade envolve pessoas, estas pessoas sãoentão os potenciais utilizadores do sítio. As actividades e as pessoas envolvidas são representadasnum esquema (os autores não referem que tipo de ferramenta se deve utilizar). As pessoasenvolvidas são então chamadas de “classes de utilizadores”. As classes de utilizadores sãoanalisadas sob o prisma de dois focus: os requisitos em termos de informação (“o quê” conceptual)e em termos de características (“quem” conceptual).

Segue-se a fase de “desenho conceptual”, que está dividida em duas partes, o modelo de13Este tipo de sítio Web tem como objectivo fornecer informação e permitir que os utilizadores naveguem nele

à procura de informação De Troyer and Leune (1998).



objectos (object modeling) e o desenho de navegação. Interessa-nos somente a primeira partede modelação, que é a modelação dos dados. Essa modelação é feita com modelos de objectosconceptuais das diferentes classes de utilizadores identificadas na fase anterior. Estes modelos sãochamados de modelos conceptuais de utilizador (User Object Models). Na modelação conceptual,os modelos de objecto descrevem os diferentes tipos de objecto, a relação entre esses objectos,regras ou restrições. Os autores apontam para a possibilidade de utilização de várias técnicasde criação de modelos conceptuais: Object Modelling Technique (OMT) Rumbaugh and Blaha(2004), ER Chen (1976) ou ORM Halpin (2006) (c.f. secção 4.2.1.3.2 De Troyer and Leune (1998).

Comentários: Este método aborda a questão da identificação dos utilizadores introduzindouma fase específica de modelação de utilizadores no seu ciclo de vida (onde são utilizadas técnicaspara a identificação dos potenciais utilizadores). É também importante referir que os autores dométodo propõem a utilização de várias (à escolha do utilizador do método) técnicas de modelaçãode dados: o ORM; ER ou OMT.

Analysis and Design of Web Based Information SystemsTrata-se de um método para a análise e construção de SIW. Este método tem as seguintesactividades: Análise ER Chen (1976), análise de cenários, desenho da arquitectura, e definiçãodos atributos. O estudo do UdD é efectuado através de uma análise utilizando a técnica ERextendido (baseado no Relationship Management Methodology Isakowitz et al. (1995)), estaanálise é feita identificando os agentes que conduzem acontecimentos que resultam em produtos(e.g. uma comissão de organização tem uma reunião que é gravada em minutos). As entidadessão categorizadas em três tipos: agente, evento e produto. Depois de definido o UdD realiza-seuma análise de cenários para entender quais são os utilizadores, quais os recursos Web necessáriose como os utilizadores visitam e usam os recursos. Esta análise é conduzida da seguinte forma:(i) identificação dos objectivos do utilizador; (ii) os cenários são definidos, descrevendo a formacomo cada objectivo definido na fase anterior é atingido Takahashi and Liang (1997).

Comentários: Utilizam a técnica ER para modelação do domínio. É ainda interessante ofacto de ser realizada a análise de cenários para compreender a dinâmica entre utilizadores erecursos.

OutrosOutros métodos existem que apresentam formas de elicitação de requisitos e modelação dedados para a concepção de sítios Web mas não trazem nada de novo em relação ao que já foirelatado. Por exemplo, Lee et al. (1999) apresentam o levantamento de cenários para a elicitaçãode requisitos e a utilização de UML para a modelação de dados; Hennicker and Koch (2000)apresentam um método em três fases, onde na fase de concepção do modelo de domínio utilizacasos de uso (Use Cases) e modelação UML para representar o UdD.



4.2.1.3.2 Métodos de desenvolvimento de softwareRational Unified Process“O Rational Unified Process (RUP) é um processo de desenvolvimento de software desenvolvidopela Rational Software. É uma abordagem à definição e gestão de tarefas, e de responsabilidadesno desenvolvimento de software numa organização. O RUP vai buscar as melhores práticas dedesenvolvimento de software moderno, apresentado-as de uma forma adaptada, o que o tornaapropriado para uma grande variedade de projectos e de organizações.” (Kruchten, 2004, p. xiii).

O RUP é um processo iterativo e incremental, havendo no final de cada iteração uma avaliação.A vantagem da existência das iterações está na identificação precoce dos riscos, sendo possívelfazer correcções a tempo. Esta abordagem iterativa e incremental é uma descoberta contínua, deinvenção e de implementação, com cada iteração a forçar a equipe de desenvolvimento a produzirartefactos cada vez mais aproximados do produto desejado pelos utilizadores finais.

O RUP apresenta-se sob duas dimensões, fases e disciplinas. Ele possui quatro fases e novedisciplinas. Podemos ver na Figura 4.4 que estas duas dimensões se cruzam. As fases sãoInception, Elaboration, Construction e Transition. Estas fases são revisitadas a cada iteraçãodo processo, cada uma delas aborda uma parte do ciclo de vida do sistema. Essa abordagemmaterializa-se nas disciplinas no eixo horizontal da figura 4.4, elas são o Bussiness Modeling, osRequirements, a Analysis and Design, a Implementation, o Test, o Deployment, a Configurationand Change Management, o Project Management e o Environment. Em cada uma das disciplinassão prouzidos artefactos que irão ser sempre actualizados a cada iteração do processo.

Figura 4.4: A arquitectura do Rational Unified Process segundo Kruchten (2004).

As actividades da disciplina de “modelação do negócio” são realizadas em grande parte na fasede Inception, mas também estão presentes um pouco na fase de Elaboration e na de Construction.Praticamente nenhuma actividade acontece na fase final de Transition.

As actividades da disciplina de “requisitos” são em grande parte realizadas na fase deInception, no entanto também estão presentes na fase de Elaboration, um pouco menos na fase



de Construction e estarão praticamente terminadas na fase de Transition.As actividades da disciplina de “análise e desenho” estão situadas basicamente na fase de

Elaboration e Construction, mas também estão um pouco presentes na fase Inception. Quasenenhuma actividade acontece na fase de Transition.

O RUP é um método complexo e muito abrangente, que permite a sua utilização em contextosde aplicação muito diferentes. O utilizador terá de adaptar o RUP ao seu contexto, identificandode entre do conjunto de artefactos propostos pelo RUP, os necessários à sua aplicação concreta.

O RUP apresenta-se como um processo “conduzido” por “casos-de-uso” (Use Case driven). Apartir dos casos-de-uso, constrói-se o modelo de casos-de-uso (que é composto pelos casos-de-usoe os actores do sistema), e identificam-se os requisitos funcionais. A partir do modelo decasos-de-uso e dos requisitos funcionais constroem-se os modelos de desenho (modelo conceptualou lógico - conforme as necessidades).

O RUP é totalmente baseado na técnica da modelação UML.

Comentários: Este método encontra-se profundamente documentado com várias publicações elivros. Tem a particularidade de ser ajustável ao contexto aplicativo. A sua forma iterativa eincremental é muito interessante para contextos onde é difícil definir requisitos, sobretudo quandonão existe possibilidade para, por exemplo, análise documental ou qualquer outra técnica deidentificação de informação do UdD. Este método utiliza em todo o seu processo de desenho edesenvolvimento a técnica UML.

Evolutionary, Object-oriented Software developmentO Evolutionary Object-oriented Software development (EOS) é baseado na ideia de que umprocesso de desenvolvimento de software deve ser decomposto em sub-processos, resultandonuma estrutura de processos fractal. Esta ideia fundamenta-se na de que em vez de associaras iterações, actividades, artefactos e milestones às fases, os processos (e as suas fases) devemestar ligados à estrutura do sistema e às suas unidades arquitecturais. Cada sub-processo tem aestrutura de “análise, desenho, implementação e operacionalização”. Cada sub-processo é entãotratado como uma actividade, e cada actividade pode ter níveis de refinamento: o sistema (topo),a componente ou o módulo (fundo). Esta estrutura de actividades é do tipo árvore em que umsistema tem várias componentes, e cada componente possui vários módulos Hesse (2003).

Comentários: Os autores deste método fazem uma forte crítica ao RUP14, apresentando-o comoseu alternativo. Introduzimos este método no nosso estudo pelo facto de apresentar uma visãodiferente no que diz respeito ao ciclo de vida, já que a estrutura de sub-processos que apresentaé radicalmente diferente da do RUP. Cada sub-processo é autónomo, permitindo a realizaçãodos ciclos de iteração dentro do mesmo sub-processo, independentemente dos ciclos iterativosrealizados nos outros sub-processos existentes.

14c.f. Hesse (2003) - pelo facto de ser um ciclo de vida baseado em fases, o que não é adequado para a maiorparte das abordagens contemporâneas de desenvolvimento de software; pela existência da dimensão das disciplinasque introduz complexidade desnecessária no processo; por não oferecer um apoio apropriado aos processos dedesenvolvimento de software complexos e ainda; pela ausência de acompanhamento da área da gestão de projecto



MethontologyO methontology é um método para o desenvolvimento de ontologias com um ciclo de vida dotipo evolutivo. De facto o que se passa é que a qualquer momento do processo é possível fazer amodificação, adição e remoção de definições.

Este método é composto por seis estados: Especificação, Conceptualização, Formalização,Integração, Implementação e Manutenção. Incluem-se ainda as actividades de planificação,aquisição de conhecimento, documentação e avaliação. Estas três últimas são simultâneas eocorrem durante todo o ciclo de vida do método. A actividade de planificação é efectuada antesde qualquer trabalho.

Só descrevemos três dos seis estados por serem os relevantes para o nosso trabalho.A “Especificação” tem como objectivo a construção de um texto (linguagem natural) com as

seguintes características: âmbito, contexto e utilização, cenários de utilização, utilizadores finais.A “Conceptualização” tem como objectivo construir o modelo conceptual. Para isso, é

construido um glossário completo de termos (a partir do documento referido na fase anterior),e de seguida é realizada uma operação de agrupamento de termos em “conceitos” e “verbos”.A partir deste agrupamento são desenvolvidos dois artefactos: “classificações por árvore deconceitos” e “diagramas de verbos”. De seguida, são aplicadas técnicas distintas para cada umdos artefactos referidos: para os conceitos o método de Gómez-Pérez et al. (1996) e para osverbos o método de Vicente (1997) .

A “Implementação” tem como objectivo a construção do artefacto “Documento de integração”.Uma ontologia deverá integrar ao máximo termos de outras ontologias, e portanto, este artfeacto,que é um documento tabela, deverá listar todos os termos e as respectivas referência aos termose ontologias que os definem. Fernández-López et al. (1997).

Comentários: As fases “Especificação” e “Conceptualização” são fases com produção dos arte-factos “Glossário” e “Âmbito”, a introduzir no método que iremos desenvolver, assim como oartefacto “Documento de integração”.

Object Role ModelingNa Europa o ORM dá pelo nome de NIAM (Natural Language Information Analysis), no entantoaqui chamar-lhe-emos ORM por ter sido este o seu nome na origem do conceito. A modelaçãode dados orientada aos factos Nijssen and Halpin (1989) é um método para modelar sistemas deinformação a um nível conceptual. Halpin (2006) refere:

“Embora semelhante em alguns aspectos à modelação ER proposta por Chen(1976), acreditamos que o NIAM fornece uma abordagem mais simples e natural àmodelação semântica.“15. (Halpin, 2006, pag. 33)

Este método utiliza idiomas naturais, assim como diagramas intuitivos - que podem ser15No original: “Although similar in some respects to ER model proposed by Chen (1976) we believe that NIAM

provides a simpler and more natural approach to semantic modeling”.



populados com exemplos - que apresentam a informação em termos de relações elementares. OORM descreve o UdD em termos de objectos (entidades e valores) que representam papeis oufunções (partes em relacionamentos) Halpin (2006). Ao contrário de outras técnicas de modelaçãode dados como por exemplo o modelo ER (c.f. Chen (1976)), ou outros orientados a objecto, oORM não utiliza atributos explicitamente. O procedimento de desenho conceptual ORM temcomo objectivo a análise e desenho dos dados. O esquema conceptual especifica a estrutura deinformação da aplicação: os “tipos de factos” que interessam, as “restrições” dos factos e algumas“regras derivativas”, para derivar alguns factos de outros factos. O método ORM ajuda a clarificaro sentido: na definição de um modelo baseado na “função do objecto” (object-role) podem criar-sedescrições do domínio precisas e cheias de significado. A modelação ORM fornece-nos formas deconcordarmos exactamente no significado do modelo. Existem várias versões de procedimento dedesenho conceptual ORM no entanto todos eles concordam na importância da verbalização emtermos de factos elementares, na verificação através da população, e na análise completa dasregras de negócio.

Segundo Halpin (2006) e Nijssen and Halpin (1989), o procedimento de desenho conceptualORM é o seguinte:

1. Transformar exemplos comuns de informação em factos elementares, e aplicar verificaçõesde qualidade;

2. Desenhar os tipos de factos, e aplicar uma verificação populando os factos;3. Verificar tipos de entidades que possam ser combinadas, e anotar todas as derivações

aritméticas;4. Adicionar restrições de unicidade, e verificar aridade de tipos de facto;5. Adicionar restrições obrigatórias de papel, e verificar se há derivações lógicas;6. Agregar valor, e definir comparações e restrições de sub-tipagem;7. Adicionar outras restrições e executar verificações finais.Halpin and Morgan (2010) apresentam o ORM como um método, já que descreve um proce-

dimento, com determinados passos, para a modelação de dados. No entanto podemos tambémfalar da técnica de modelação ORM como sendo uma técnica para construir modelos conceptuaisde um sistema de informação.

Comentários: Uma vez que este método aborda a modelação semântica de uma forma muito maissimples e natural, e sendo a modelação semântica a essência do desenvolvimento de um DCAP,a técnica ORM será uma das alternativas a utilizar na fase de modelação do domínio do DCAP.

4.2.1.4 Sumário

As actividades do Rigor Cycle levantaram, em resumo, a seguinte base de conhecimento paraalimentar as actividades de construção do Design Cycle:Métodos e Processos

Analysis and Design of Web based Information Systems Takahashi and Liang (1997), Evo-



lutionary, Object-oriented Software development Hesse (2003), Relationship ManagementMethodology Isakowitz et al. (1995), Rational Unified Process Kruchten (2004), Web SiteDesign Model De Troyer and Leune (1998), Methontology Fernández-López et al. (1997),

TécnicasObject Modelling Technique Rumbaugh and Blaha (2004), Object Role Modelling Halpinand Morgan (2008), Unified Model Language Fowler (2004), Entity-Relationship ModelChen (1976).

4.3 Espaço Design Science Research

No Espaço DSR realizam-se as actividades do Design Cycle (c.f. Figura 4.5). Este ciclo éaltamente iterativo, as actividades deslocam-se entre dois momentos de trabalho:

• O da concepção do artefacto, o Me4DCAP. Estas actividades dizem respeito ao processode construção do Me4DCAP, elas estão descritas na secção 4.3.1;

• O do teste do artefacto, onde o Me4DCAP vai sendo aplicado à medida que é construído.Para isso utilizamos uma “situação experimental” Hevner (2007), integrando uma equipede desenvolvimento do DCAP-ESS. Esse trabalho está relatado na secção 4.3.2.

Figura 4.5: Esquema da aplicação específica do enquadramento metodológico - Espaço DesignScience Research.

Estes dois trabalhos alimentaram-se mutuamente: a “concepção do método” foi bebendodas conclusões que iamos retirando do trabalho da “situação experimental”; e a “situaçãoexperimental” foi desenvolvendo o seu trabalho baseado nas directivas do Me4DCAP. Realizamosassim os micro-ciclos de construção e avaliação definidos no enquadramento de Hevner (2007).

De seguida apresentamos as actividades de Design Cycle desenvolvidas, e a forma como seinfluenciaram mutuamente.



4.3.1 Processo de construção do Método para o Desenvolvimento de DublinCore Application Profiles

O DCAP está definido no Enquadramento de Singapura (c.f. Nilsson et al. (2008)) e no guiada DCMI (c.f. Baker and Coyle (2009)). Para construir um DCAP é necessário realizar umconjunto de actividades que ao longo do tempo irão devolver os seguintes deliverables:

• Requisitos funcionais (obrigatório);• Modelo de domínio (obrigatório);• DSP (obrigatório);• Guias de utilização (não obrigatório);• Guias de sintaxe (não obrigatório).O ponto de partida para a concepção do Me4DCAP é o RUP, por se tratar de um método

que aborda profundamente todas as fases de desenvolvimento de um software. Foi desenvolvidohá 20 anos (nos anos noventa), assimilando as melhores práticas de desenvolvimento de software,e apresentando-as de forma a se adaptarem a um conjunto vasto de situações, projectos ouorganizações Kruchten (2004). Segundo Kroll and Kruchten (2003), citado por Borges (2008),o RUP era utilizado em 2008 em mais de 10000 organizações, em projectos tanto de pequenacomo de grande envergadura Borges (2008), demonstrando assim ser um método consistente ecom muita maturidade. Por outro lado, o facto de existir um grupo de especialistas RUP nolaboratório onde este projecto de doutoramento está enquadrado16 foi um factor para que oescolhessemos como ponto de partida para a construção do Me4DCAP. O RUP, como veremos,será afinado às nossas necessidades - o que está perfeitamente nos seus objectivos - introduzindoalgumas adaptações de ajuste ao nosso contexto. Isso acontece porque:

• o constructo DCAP traduz um modelo de dados. O nosso objectivo final no desenvolvimentode um DCAP é portanto um constructo-modelo de dados per se, ao contrário do que aconteceno RUP cujo objectivo final de desenvolvimento é um artefacto de software.

• pelo facto descrito no ponto anterior, não interessa integrar algumas das actividades doRUP que estão para além da modelação dos dados. O RUP é um processo composto porquatro fases (c.f. Secção 4.2.1.3.2). As duas primeiras fases (Inception e Elaboration)possuem actividades relacionadas com a definição de requisitos e de modelação de dados.Estas actividades estão totalmente dentro do que é o desenvolvimento de um DCAP, noentanto a terceira fase de Construction possui actividades de programação que não sãode todo actividades necessárias no desenvolvimento do DCAP. A fase Transition tem asacividades de validação que interessam. Foram portanto redefinidas as fases, e analisadas àluz das necessidades do DCAP para identificar as respectivas actividades;

• o RUP é essencialmente um processo para o desenvolvimento de software em organizaçõesbem delimitadas em âmbito e dimensões. Um DCAP não se enquadra num contexto deimplementação ao nível de uma organização mas sim ao nível de uma comunidade deinteresses comuns, na Web. Trata-se de um contexto completamente aberto, onde ospotenciais utilizadores são, grande parte deles, desconhecidos;

16Ver Centro Algoritmi na Universidade do Minho: http://algoritmi.uminho.pt


http://algoritmi.uminho.pt


• O RUP para além das fases tem um conjunto de disciplinas Business Modeling, Require-ments, Analysis & Design, Implementation, Test, Deployment que segundo Hesse (2003)acrescentam uma complexidade desnecessária ao processo. Adaptaremos esta dimensão -que segundo Hesse (2003) se sobrepõe às fases - ao nosso caso: elas passam a ser as Etapasdo Enquadramento de Singapura.

O Me4DCAP foi definido em quatro fases (c.f. Figura 4.7) (colunas da figura): “Definição deâmbito”, “Construção”, “Desenvolvimento” e “Validação”. Estas fases são atravessadas (linhasda figura) ao longo do projecto pelas actividades das Etapas de Singapura. Baseámo-nos noRUP para definir as fases, como já referimos anteriormente, adaptando-as ao nosso contexto,acrescentando contributos de outros métodos, e informação recolhida nas já referidas entrevistasrealizadas. Nas primeiras versões do Me4DCAP definimos as Etapas de Singapura Desenvolveros Guias de Utilização e Desenvolver os Guias de Sintaxe como iniciando-se ainda na fase“Construção” (c.f. Figura 4.6), no entanto na versão final concluímos que estas deveriam iniciar-sesomente na fase de “Desenvolvimento” já que até essa fase não há informação disponível paraexecutar as actividades destas duas etapas.

Figura 4.6: As fases do Method for the Development of Dublin Core Application Profiles V0.1 eV0.2

4.3.1.1 Ciclo de vida

Existem essencialmente três ciclos de vida de software, como já vimos na secção 4.2.1.3. Eles são:“modelo em Cascata”, “modelo Iterativo e Incremental”, e “modelo Evolutivo e Adaptativo”. Omodelo em Cascata obriga à definição de todos os requisitos no início, e a implementação deve serum espelho da especificação, isto é, tem de satisfazer a definição dos requisitos Fernández-Lópezet al. (1997). Ora no caso presente, de desenvolvimento de um DCAP, a definição dos requisitosà partida é algo muito difícil pela natureza aberta do sistema onde o DCAP funciona, a Web;e por geralmente ser difícil realizar uma análise documental, técnica com frequência utilizadapara a definição de requistos. O que acontece é que o desenvolvimento de um DCAP é realizado



Figura 4.7: As fases do Method for the Development of Dublin Core Application Profiles V1.0.

tendo como alvo uma comunidade de prática, abrangendo utilizadores desconhecidos, em toda adimensão da Web - pode tornar-se complexa a tarefa de definição de requisitos. Por esta razão,o Me4DCAP deverá permitir uma realimentação tal, de forma a poderem ser integradas novas“descobertas” nos artefactos produzidos, e consequentemente nas Etapas do DCAP. É necessárioentão introduzir interação no processo de modo a permitir esta realimentação referida.

Como vimos na secção 4.2.1.3.2, ambos os métodos RUP e EOS possuem ciclos de vidaiterativos e incrementais. O primeiro efectua uma iteração no processo completo, enquanto que nosegundo, a iteração é feita em cada sub-processo. Além destes métodos, o desenvolvedor do DCAPVMAP (c.f. em Apêndice 4.1.2.3) também refere ter integrado iteractividade no processo globalde desenvolvimento, realimentando novos requisitos no processo após a validação. O métodoRMM (c.f. secção 4.2.1.3.1) apresenta um modelo misto, permitindo a iteração nas sub-etapasdo processo global. Pensamos inicialmente que para o caso presente era mais apropriado estaabordagem do RMM. Isto porque, não sendo possível definir os requisitos à partida, no percursode desenvolvimento podemos sentir a necessidade de voltar à etapa anterior para correcção dealguma falta. A Figura 4.817 apresenta as fontes na literatura em que nos baseamos para adefinição do ciclo de vida.

O ciclo de vida do Me4DCAP foi inicialmente definido como iterativo e incremental mas, apósos inputs do FG, passamos a defini-lo como do tipo evolutivo e adaptativo. Além disso, aindaapós a reunião do FG houve uma viragem de paradigma, e passou-se a fazer uma abordagemao processo e não ao deliverable. Nas primeiras versões (c.f. Figura 4.9) apresentou-se umaimagem rígida do ciclo de vida, com a indicação do percurso a realizar entre artefactos. Naversão final (c.f. Figura 4.13) apresenta-se o flow das actividades, e o método refere claramenteque a qualquer momento se pode voltar atrás no processo.

As Figura 4.9 e 4.13 apresentam a sequência das actividades. Na Figura 4.9a e 4.9b,por termos uma abordagem ao artefacto, vemos a sequência da definição dos artefactos, naFigura 4.13, por termos uma abordagem ao processo, vemos a sequência das actividades. As

17Todas as figuras apresentando as bases de conhecimento para a construção do Me4DCAP não têm legenda.Para consultar a legenda ver Apêndice E.



(a) V0.1 e V0.2. (b) V1.0.

Figura 4.8: Bases de conhecimento para a definição das fases e do ciclo de vida do Method forthe Development of Dublin Core Application Profiles.

alterações existentes do ciclo de vida acontecem na forma como as actividades se encadeiam,onde se iniciam e onde terminam. Da primeira versão para a segunda, a alteração está somenteno momento em que se inicia o desenvolvimento dos Guias de Utilização e de Sintaxe. Naúltima versão vemos que o encadeamento das actividades está mais bem definido, e altera-serelativamente ao que estava definido nas versões anteriores. Podemos ver que:

• O Glossário desenvolve-se, na versão final, ao longo de todo o processo de desenvolvimentodo DCAP (não incluindo a actividade de validação da produção) enquanto que nas versõesanteriores o seu desenvolvimento termina no momento anterior à definição do deliverableDSP. Esta alteração é influenciada pela reflexão saída da “situação experimental“.

• O desenvolvimento dos Guias de Utilização, na versão final, inicia-se logo após a definição dodeliverable Modelo de Domínio e terminam no final do processo (não incluindo a actividadede validação da produção), enquanto que nas versões anteriores se inicia ao mesmo tempoque o desenvolvimento do artefacto Modelo de Casos de Uso e termina no momento anteriorà definição do deliverable DSP;

• O desenvolvimento dos Guias de Sintaxe, na versão final, inicia logo após a definição dodeliverable Modelo de Domínio e terminam no final do processo (não incluindo a actividadede validação da produção). Esta alteração é influenciada pelo processo de reflexão após osinputs da validação FG. Nas versões anteriores:– Na V0.1: inicia-se ao mesmo tempo que o desenvolvimento do artefacto Modelo de

Casos de Uso e termina no momento anterior à definição do deliverable DSP;– Na V0.2: inicia-se ao mesmo tempo que o desenvolvimento do artefacto Modelo de

dados detalhado e termina ao mesmo tempo que o fim da definição do deliverableDSP.

Esta alteração é influenciada pela reflexão saída da “situação experimental“.

Para além destas alterações no tempo de início e fim de actividades, há ainda alterações quedizem respeito à introdução de novas actividades, que dão origem a artefactos não existentesnas versões anteriores. Isto acontece após os inputs da validação FG. Estas alterações estãomencionadas nas secções 4.3.1.3, 4.3.1.4 e 4.3.1.5.



(a) V0.1.(b) V0.2.

Figura 4.9: O ciclo de vida do Me4DCAP.

4.3.1.2 Equipa de trabalho

O RUP define o perfil de cada um dos stakeholders de uma equipe de trabalho de um projectode desenvolvimento de software. À luz da definição do RUP, retirámos os elementos necessáriospara o nosso caso particular, adaptando ao contexto (não só em termos de nome como de funçõesa exercer), utilizando a informação retirada das entrevistas. Elas apresentaram informaçõessobre o perfil das pessoas que integraram as equipes de trabalho. Definimos, na primeira versãodo método, 4 tipos de stakeholders que podem interagir no processo de desenvolvimento de umDCAP: Gestor, Analista de Sistema, Programador de Metadados e Utilizador Final.

Na segunda versão introduzimos alterações porque:• a “situação experimental” deu alguns inputs relativamente à definição da equipe de tra-balho de desenvolvimento de um DCAP. Na realidade a equipa foi escolhida a partirda disponibilidade das pessoas e não a partir das suas competências. Por coincidênciahavia dois participantes que eram analistas de sistemas mas não tinham conhecimento àdata de modelação semântica. Todos eles eram especialistas do domínio de aplicação. Otrabalho mais técnico foi realizado por nós. À medida que fomos desenvolvendo os trabalhoidentificámos a necessidade de dividir a equipe em duas, a técnica e a alargada;

• as entrevistas confirmaram o experienciado no ponto anterior, relativamente à separaçãode tarefas;



• a discussão na sessão de apresentação da versão 0.1 do Me4DCAP, na conferência ElPub2013, deu espaço a mais reflexão.

Estas alterações aconteceram tanto no nome de alguns perfis como na sua descrição:Gestor de Projecto

Um Gestor de Projecto “assume a visão global do projecto através de uma interacçãodetalhada com os participantes internos e externos” (Borges et al., 2012, p. 63). Deveráser uma pessoa que pertence às organizações que estão empenhadas no desenvolvimento doDCAP. Esta pessoa deverá ter uma visão do âmbito da Organização e do objectivo quepretende alcançar com este desenvolvimento.

Analista de SistemasO Analista de Sistemas deverá ter conhecimentos em duas vertentes: (i) competênciastécnicas em elicitação de requisitos e em modelação de dados; (ii) “conhecimentos básicosde gestão”, comprender em detalhe o domínio de aplicação e ainda entender “a motivaçãoreal e a relevância dos requisitos” (Borges et al., 2012, p. 62).

IntegradorO Integrador deverá ser um desenvolvedor/desenhador de metadados que compreende osconceitos da Web Semântica, que tem conhecimentos técnicos em DSP e RDF.

Utilizador FinalO Utilizador Final é um utilizador que trabalhará com o sistema Web que irá implementaro DCAP.

Na versão final, mais alterações aconteceram com os inputs do FG: c.f. secção 4.1.3.2.

4.3.1.3 Desenvolver os Requisitos Funcionais

Há duas actividades que se desenrolam ao logo de todo o processo de desenvolvimento de DCAP:• o desenvolvimento do Glossário: esta actividade devolve o artefacto Glossário no final dos

trabalhos. Ela é definida desde a V0.1.• o desenvolvimento da documentação DCAP: Esta actividade devolve um conjunto dedocumentos que definem a documentação do DCAP. Ela não existia nas V0.1 e V0.2, éintroduzida após os inputs da validação FG (c.f. Figura 4.10b).

(a) Artefacto Glossário. (b) Artefacto Documentação do DCAP.

Figura 4.10: As bases de conhecimento para a definição dos artefactos Glossário e Documentaçãodo DCAP.

A Figura 4.10a mostra que nos baseamos no método Methontology Fernández-López et al.(1997) e no RUP Kruchten (2004) para incluir o artefacto Glossário no processo de desenvolvi-mento.



Para desenvolver os Requisitos Funcionais, é necessário realizar uma série de actividades.Estas actividades irão no final produzir cinco artefactos e um deliverable de Singapura:

1. Plano de Trabalho;2. Documento Visão;3. Requisitos de Alto-nível (Na V0.1: Descrição Alto-nível dos Casos-de-Uso; Na V0.2:

Expressão dos Requisitos Funcionais);4. Estado da Arte do Contexto de Aplicação;5. Modelo dos Casos-de-Uso;6. Requisitos Funcionais.Relativamente aos três primeiros artefactos, eles são definidos pelo RUP como uma forma para

desenvolver Requisitos Funcionais. O método Web Site Design Model (WSDM) (ver Calverley andJohnston (2009)), e o TBM AP DCAP (ver De Troyer and Leune (1998)) usaram um DocumentoVisão como um processo para a construção dos requisitos funcionais (ver Figuras 4.11). Aalteração do nome dos Requisitos de Alto-nível entre a versão 0.1 e 0.2 reflecte um ciclo dereflexão imposto pelos trabalhos da “situação experimental“. O novo nome é mais adequado àfunção do deliverable: uma descrição que expressa os desejos de funcionalidade para o DCAPpor parte do grupo de trabalho.

(a) V0.1. (b) V0.2.

Figura 4.11: As bases de conhecimento para a definição dos deliverables Plano de Trabalho,Documento Visão e Descrição Alto-nível dos Casos-de-Uso (V0.1) ou Expressão dos RequisitosFuncionais (V0.2).

A versão final (c.f. Figura 4.12): (i) introduz a necessidade de desenvolver o Estado da Artedo Contexto de Aplicação na actividade Desenvolver os Requisitos Funcionais e não na actividadeDesenvolver o pré-Description Set Profile; (ii) altera o nome do artefacto que na V0.2 se chamava”Expressão dos Requisitos Funcionais“ para ”Requisitos de Alto Nível“. Estas alterações foramintroduzidas devido ao input da sessão de validação FG.



Figura 4.12: As bases de conhecimento utilizadas para a definição dos deliverables Plano deTrabalho, Documento Visão e Estado da Arte contexto de aplicação e Requisitos de alto nível -V1.0.



Figura 4.13: Detalhe da interligação das actividades do Method for the Development of Dublin Core Application Profiles V1.0.Contributo metodológico para o desenvolvimento de perfis de aplicação no contexto da Web Semântica 81


Para desenvolver o Modelo de Casos-de-Uso é necessário realizar duas actividades quedevolvem dois artefactos:

• diagrama UML dos Casos-de-Uso;• Casos-de-Uso detalhados.Todos os DCAP estudados: TBM AP Calverley and Johnston (2009), SWAP Allinson and

Powell (2006), VMAP Iglesias et al. (2009), Images Application Profile (IAP) Eadie (2008) eDRYAD Carrier (2008); o método ADWIS Takahashi and Liang (1997); e a seguinte literaturaIMS Global Learning Consortium, Inc. (2005a), Friesen et al. (2002), DCMI (nd) e Buonaziaand Masci (2007) referem a necessidade de construir um Modelo de Casos-de-Uso como etapa dodesenvolvimento dos Requisitos Funcionais (c.f. Figura 4.14).

Figura 4.14: As bases de conhecimento para a definição do artefacto Modelo de Casos-de-Uso

Os Requisitos Funcionais são o primeiro deliverable do processo desenvolvimento de umDCAP. Como podemos ver na Figura 4.15, o RUP define a necessidade de construir RequisitosFuncionais no processo de desenvolvimento de software. Além disso, todos os DCAP estudadosdefiniram Requisitos Funcionais (aliás não poderia ser diferente já que de outra forma nãopoderiam ser chamados de DCAP uma vez que é um deliverable obrigatório do Enquadramentode Singapura). Além disso, a literatura seguinte também refere a necessidade de desenvolverRequisitos Funcionais: Chen and Chen (2005), BSI (2005), IMS Global Learning Consortium,Inc. (2005a), CWA (2006), de La Passadière and Jarraud (2004) and Eadie (2008), e os GuiasDCMI (c.f. Baker and Coyle (2009)).

4.3.1.4 Desenvolver o Modelo de Domínio

Para desenvolver o Modelo de Domínio, é necessário realizar uma série de actividades. Estasactividades irão no final produzir o artefacto Environmental Scan e o deliverable Modelo deDomínio.

O desenvolvimento do Environmental Scan (nas versões anteriores chamado de Relatório doestado da arte) foi definido, após o input da validação FG, para ser desenvolvido em paralelocom o desenvolvimento do Modelo de Domínio. Anteriormente ele era desenvolvimento aquandodo desenvolvimento do Pré-DSP (c.f. 4.18). A Figura 4.16 mostra que todos os DCAP por nósanalisados realizaram o Estado da Arte; Chen and Chen (2005), BSI (2005), Onyancha et al.



(2001), Agostinho et al. (2004), Marzal Garzía-Quismondo et al. (2006), Buonazia and Masci(2007) e Salokhe et al. (2008) também realizaram o estado da arte.

O modelo de domínio, por ser obrigatório no Enquadramento de Singapura, foi desenvolvidopor todos os DCAP estudados. O RUP (c.f. Kruchten (2004)) e o método WSDM (c.f. De Troyerand Leune (1998)) também referem da necessidade de desenvolver o Modelo de Domínio; o Guiada DCMI e o Enquadramento de Singapura também, como é natural. Além disso, Onyancha etal. (2001) e Eadie (2008) referem também a necessidade de desenvolver um Modelo de Domínio(c.f. Figura 4.17).

Ainda relativamente ao desenvolvimento do Modelo de Domínio, a Figura 4.17 apresenta asvárias técnicas utilizadas pela comunidade para desenvolver o Modelo de Domínio. O DCAPSWAP utilizou um diagrama de classes UML (ver Fowler (2004)) sem detalhes, assim comoo reportado em Onyancha et al. (2001). O RUP (ver Kruchten (2004)), sendo um processocentrado no UML, também utiliza esta técnica. O método WSDM (ver De Troyer and Leune(1998)) refere que várias técnicas podem ser utilizadas: UML, o Object Modeling Technique(OMT) (ver Rumbaugh et al.(1990)), ORM (ver Halpin (2006)), ER (ver Chen (1976)). Eadie

Figura 4.15: As bases de conhecimento utilizadas para a definição do deliverable RequisitosFuncionais.

Figura 4.16: As bases de conhecimento para a definição do artefacto Environmental Scan.



(2008) também reporta no seu trabalho a utilização de ER.Na validação FG referiu-se que qualquer técnica pode ser utilizada. O importante é que a

equipe de trabalho comunique bem com a técnica escolhida.

4.3.1.5 Desenvolver o Description Set Profile

Para desenvolver o DSP, é necessário realizar uma série de actividades. Estas actividades irão nofinal produzir os seguintes artefactos:

• o Pré-Description Set Profile:– Modelo de dados detalhado;– Alinhamento de vocabulários;– Matriz de restrições.

• Critérios de adequação;• Validação em laboratório:

– Teste de adequação;– Teste em laboratório;– Questionário.

E ainda o deliverable de Singapura DSP.O nome dos artefactos teve uma evolução da V0.1 para a versão final (V1.0). Isso deveu-se

aos inputs da validação FG. Relativamente ao Pré-DSP, as alterações foram:• De Dossier de Validação para Pré-DSP;• De Documento de Integração para Matriz de Restrições;

Figura 4.17: As bases de conhecimento para a definição do deliverable Modelo de Domínio.



• De Diagram ORM Modelo de Dados para Modelo de Dados Detalhado;O artefacto Relatório do estado da arte é na, versão final, realizado em paralelo com o

desenvolvimento do Modelo de domínio, e o seu nome foi alterado para Environmental scan(c.f. secção 4.3.1.4. Um novo artefacto é introduzido após a validação FG, o Alinhamento devocabulários.

Relativamente à Validação em Laboratório, as alterações foram:• De Dossier Validação para Validação em Laborário;• De Relatório de Validação para Teste de Adequação;• De Documento de Validação para Teste em Laboratório.A Figura 4.18 mostra que o Pré-DSP foi referido pelo método Methontology (ver Fernandez et

al. (1997)) e ainda por CWA (2006); ainda os Guias DCMI apresentam um artefacto como este.A matriz de restrição foi construída a partir de uma base existente no Guia DCMI (c.f. Baker& Coyle (2009)) e adaptada e ajustada a partir do trabalho realizado no âmbito da ”situaçãoexperimental”. A Figura 4.19 mostra as alterações ao nível da nomenclatura introduzidas apósvalidação FG.

A “situação experimental” dentro do enquadramento deste projecto de doutoramento terminouno ponto do desenvolvimento do deliverable DSP, tendo sido realizado o artefacto Pré-DSPmas não o Teste em Laboratório nem o artefacto Critérios de Adequação. Este trabalho estáprojectado para ser realizado em trabalho futuro. Por essa razão a “situação experimental” nãoé mais referida a partir deste ponto.

Figura 4.18: As bases de conhecimento utilizadas para a definição do artefacto Pré-DescriptionSet Profile V0.1 e V0.2.

A Figura 4.20 mostra que os DCAP SWAP Allinson and Powell (2006) e VMAP Iglesias et al.(2009) também utilizaram um Documento de Validação para realizar validação em laboratório.Agostinho et al. (2004) também utilizou a mesma técnica. A Figura 4.20b mostra as alteraçõesao nível da nomenclatura introduzidas após validação FG.

O artefacto Critérios de Adequação foi introduzido após validação FG (c.f. 4.21).O RUP integra uma actividade de validação em produção (ver Figura 4.22). Na validação

FG confirmaram a importãncia desta actividade no Me4DCAP referindo no entanto que esta



Figura 4.19: As bases de conhecimento utilizadas para a definição do artefacto Pré-DescriptionSet Profile V1.0.

(a) V0.1 e V0.2. (b) V1.0.

Figura 4.20: As bases de conhecimento utilizadas para a definição do artefacto Validação emLaboratório.

Figura 4.21: O artefacto Critérios de Adequação definido na validação Focus Group.



poderia estar fora do domínio da equipe de trabalho.

Figura 4.22: O Rational Unified Process como base de conhecimento utilizada para a definiçãodo artefacto Validação em Produção.

4.3.1.6 Desenvolvimento dos Guias de Utilização e dos Guias de Sintaxe

A Figura 4.23 mostra que os dois Guias foram referidos no Enquadramento de Singapura,naturalmente, e no Guia DCMI. O RUP também refere a importância de desenvolver guias deutilização para que as implementações sejam de qualidade.

Figura 4.23: As bases de conhecimento utilizadas para a definição dos deliverables Guias deUtilização e Guias de Sintaxe.

4.3.1.7 Considerações finais

O caminho percorrido na construção do Me4DCAP é apresentado no Apêndice E. Aí apresentamosas bases de conhecimento utilizadas, que justificam a existência dos vários artefactos definidos:

• Na Figura E.1, na primeira versão do método - Me4DCAP V0.1;• Na Figura E.2, na segunda versão do método - Me4DCAP V0.2.

A Figura 4.24 apresenta as bases de conhecimento utilizadas para a definição do Me4DCAPV1.0, e resultado final deste projecto de doutoramento (apresentado no Capítulo 5).



Figura 4.24: Base de conhecimento utilizada para a definição de Method for the Development of Dubin Core Application Profiles V1.0



4.3.2 Situação experimental

Após o trabalho da primeira fase descrito na secção 6.2.2.4.2, onde entrevistamos alguns líderesmundiais da ESS para estudar a questão de interoperabilidade dos SIW da ESS (visto não haverliteratura sobre esse assunto), e após termos acompanhado os trabalhos do consórcio RéseauxIntercontinental de Promotion de l’Économie Social Solidaire (RIPESS) descritos no Apêndice B,na Secção B.1, a solução que encontramos para a necessidade de interoperabilidade entre os SIWda ESS foi a de desenvolver um DCAP (DCAP-ESS).

Esta fase dos trabalhos arrancou em Julho de 2012, quando foi enviada uma mensagem decorreio electrónico ao consórcio18 onde se apresentou uma resenha do projecto de investigação.Nesse email, onde se referiu que iria ser enviada uma proposta de planeamento do nosso trabalhofuturo, pergunta-se da disponibilidade de cada um dos membros para participarem neste trabalhode desenvolvimento de um DCAP-ESS, seguindo o método a desenvolver por nós. Obtivemosrespostas positivas do FBES e do ZOES. Estas duas pessoas foram as que deram a continuidadeentre as duas fases do projecto, outros se lhes juntaram. Formou-se, nos dois meses seguintes,uma equipe para desenvolver o trabalho; esta equipe foi estabelecida pelos parceiros FBES eZOES. Todos os membros da equipe eram especialistas na área de aplicação do DCAP; alémdisso tinham outras competências. A equipe era constituída por:

• Daniel Tygel (Brasil): analista de sistemas na cooperativa EITA19 e gestor de redes deESS;

• Alan Tygel (Brasil): analista de sistemas e programador na cooperativa EITA, e investigadorem Linked Open Data na Universidade Federal do Rio de Janeiro;

• Jason Nardi (Itália): gestor de redes de ESS;• Craig Borowiak (Estados Unidos da América): especialista em ESS e investigador emCiências Políticas na Haverford University, nos Estados Unidos da América.

Propusemo-nos assumir o papel de líderes deste processo de desenvolvimento; era de factouma estratégia nossa para possuirmos uma “situação experimental” para os momentos deavaliação do Design Cycle. O consórcio RIPESS aceitou a proposta, criando um novo grupo,de nome ESSGlobal. Estas reuniões foram realizadas utilizando o programa Skype somentena componente audio. As sessões foram gravadas e disponibilizadas para todos os presentesnuma pasta dropbox partilhada. O projecto utilizou um Wiki para documentar o processo, ea ferramenta PONTAOPAD20 como livro de registo (Log-Book) das reuniões. O Wiki podeser acedido através do endereço http://purl.org/essglobal/wiki (nome do utilizador: guest;palavra-passe: guest). Ele tem toda a informação actualizada do processo de desenvolvimento doDCAP-ESS.

Os trabalhos de desenvolvimento do DCAP-ESS e da concepção do Me4DCAP iniciaram-seao mesmo tempo; os dois trabalhos foram feitos em paralelo influenciando-se mutuamente. Noinício dos trabalhos do DCAP-ESS, o Me4DCAP estava numa versão embrionária, tinha jábebido das actividades dos ciclos Rigor e Relevance. No entanto, não havia uma visão a longo

18Aos presentes na reunião de Paris - c.f. secção B.1.1.19http://www.eita.org.br - acedido em 24.09.2013.20Ver http://pontaopad.me/ - acedido em 30 de Out de 2013.


http://purl.org/essglobal/wiki

http://www.eita.org.br

http://pontaopad.me/


prazo dos trabalhos a serem realizados. Por isso não pudemos dizer claramente ao grupo qual ocaminho a seguir; esse caminho foi sendo definido à medida que avançávamos com o trabalho dedesenvolvimento do Me4DCAP.

A última reunião de trabalho com a equipa alargada da ESSGlobal foi a 9 de Abril de 2013,com uma primeira versão do Modelo de Dados Diagrama ORM definido21. O Modelo de Domíniotinha sido validado pela equipe de trabalho. No entanto os Requisitos Funcionais não foramvalidados.

Todo o trabalho que se seguiu foi realizado pela equipe técnica, que incluía dois elementosda ESSGlobal. As actividades da Etapa de Singapura DSP foram parcialmente realizadas: nãose desenvolveu a actividade de validação em laboratório. A última reunião da equipe técnicaaconteceu no dia 5 de Fevereiro de 2014, data da última reunião dentro do enquadramento destetrabalho de doutoramento.

No caso do nosso projecto não foi possível escolher as pessoas pelas suas competências comodefinido no Me4DCAP, o que tornou o desenvolvimento mais lento e mais difícil. Entendemos aimportância da existência das várias competências definidas pelo Me4DCAP de cada membro daequipe, e de como o trabalho de desenvolvimento de um DCAP pode ser efectivamente repartidopor uma equipe mais técnica e outra menos técnica - algo que foi referido também nas entrevistascom os desenvolvedores DCAP VMAP e SWAP - e que aparece claramente explícito na versãofinal do Me4DCAP.

Em Apêndice, na secção B.2, apresentamos o registo dos trabalhos efectuados com este grupoda ESSGlobal. De seguida passamos a descrever os passos deste trabalho, e pontos importantesretirados para a construção do artefacto Me4DCAP.

Na primeira reunião, em 23 de Outubro de 2012, é feita a contextualização do processo, de-fine-se a equipe e o plano de trabalho.

Obtivemos os seguintes resultados da reunião para alimentar o artefacto Me4DCAP:• Identificamos a importância de introduzir no método a possibilidade de utilizar modelos de

dados já existentes (que suportam bases de dados existentes) nas organizações ou qualquerdocumento das organizações com informação que pudesse ajudar a definir o modelo dedados - no caso presente, por se tratarem de várias organizações em várias localizações domundo, a possibilidade de análise de documental era uma questão complexa;

• Identificamos a problemática de ser um ambiente demasiado heterogéneo e aberto, istoporque o DCAP-ESS iria servir não só as organizações da ESSGlobal, como muitas outrasno mundo inteiro, muitas delas até desconhecidas - não era possível prever quem iria utilizaro DCAP-ESS. Trata-se efectivamente um problema subjacente a todas as concepções deDCAP, e isto acontece devido à própria natureza da Web Semântica.

Na segunda reunião, a 6 de Novembro de 2012, é planeado que o processo comece com odesenvolvimento de um Plano de Trabalho e um Documento Visão. Estes dois documentos devemser os primeiros a ser desenvolvidos; após a sua conclusão, o desenvolvimento de outros artefactosse seguiria. Além disso planeamos introduzir a necessidade do desenvolvimento de um Glossário,sendo um documento que deve ser desenvolvido ao longo do processo.

21O nome deste artefacto na altura. Na versão final (c.f. capítulo 5) tem o nome de modelo de dados detalhado



Obtivemos os seguintes resultados da reunião para alimentar o artefacto Me4DCAP:• Identificamos a necessidade de ter uma ferramenta de trabalho colaborativa. Ficamosresponsáveis por tornar disponível um Wiki, de o confgurar para dar acesso de escrita atodos os membros, e de configurar os documentos Visão e Glossário para o trabalho deconstrução colaborativo no Wiki.

• Apesar de ainda não termos terminado a elaboração do documento Visão, o grupo desejouavançar de imediato para a elaboração de algo mais concreto. Propusemos a elaboração dosCasos-de-uso. Foram identificados os primeiros casos de uso, e o trabalho foi distribuídopelos vários membros do grupo, que ficaram de escrever sobre eles;

• Este trabalho seria feito em pararelo com os outros dois documentos (Visão e Glossário).Não era o que tinhamos planeado, mas a pressão do grupo para avançar era demasiadogrande, não viam a necessidade de ficar a trabalhar somente sobre estes dois documentos.Concordamos que cada grupo tem o seu ritmo e sua cultura de trabalho, e que um métodonão deve ser demasiado rígido, dando uma certa liberdade no seu ciclo de vida.

Na terceira reunião, a 4 de Dezembro de 2013, planeamos que toda a equipe de trabalhoestivesse envolvida na elaboração dos Casos-de-Uso. Concluimos que o desenvolvimento dosCasos-de-Uso deverá ser elaborado pelos elementos da equipe de trabalho que conhecem o domíniode aplicação mas é necessário serem assessorados por elementos com competências de análise desistemas.

Obtivemos os seguintes resultados da reunião para alimentar o artefacto Me4DCAP:• O plano de trabalho foi revisto e reformulado - importante poder fazê-lo de forma a irajustando o tempo ao trabalho que vai sendo desenvolvido;

• Foram apresentadas cinco descrições dos Casos-de-Uso. Alguns membros da equipa apre-sentaram textos com as descrições. Foram discutidos os casos-de-uso.

• Para uniformizar o trabalho, o líder do grupo ficou de disponibilizar um modelo de textopara apresentar os Casos-de-Uso na Dropbox. Cada membro iria desenvolver o seu Caso eregistá-lo no modelo disponibilizado, colocando os ficheiros na Dropbox. O líder do grupoficou responsável de os organizar posteriormente no Wiki, quando terminados.

• A necessidade de ter um modelo para o preenchimento dos casos mostrou ser uma maisvalia. Tal recurso ajuda sobretudo para pessoas com perfil não técnico.

Na quarta reunião, a 8 de Janeiro de 2013, planeamos que toda a equipe de trabalho estivesseenvolvida na elaboração dos Casos-de-Uso, que começariam a tomar forma. O trabalho seguinteseria o da elaboração do Diagrama UML de casos-de-uso para completar o Modelo de Casos-de-usode forma a poderem ser desenvolvidos os Requisitos Funcionais. Estes dois artefactos poderiamser elaborados pelos elementos do grupo de trabalho de perfil mais técnico, e depois seriamapresentados a toda a equipe para validação final.

Obtivemos os seguintes resultados da reunião para alimentar o artefacto Me4DCAP:• Uma vez que nenhum membro da ESSGlobal desenvolveu o documento Visão a tempodesta reunião, decidimos tomar em mão a escrita deste documento. No entanto a Visãoé um documento que deve ser assumido pela equipe de trabalho. O que aconteceu foiuma discussão à volta do que tinha sido escrito por nós, elementos sem competências de



especialista de domínio. Um membro (elemento com perfil especialista de domínio deaplicação e notoriamente líder do grupo ESSGlobal) não assumiu a Visão por nós escrita eficou responsável por fazer a sua reformulação;

• Identificamos a necessidade absolutamente obrigatória de ter um elemento no grupo comconhecimentos de conceitos subjacentes à modelação de dados para esquemas de metadados.Verificamos que os dois elementos com um perfil mais técnico do grupo da ESSGlobaltinham forte experiência de desenvolvimento de projectos em bases de dados relacionais; oseu raciocínio teve de ser guiado e adaptado à nova realidade.

Na quinta reunião, a 18 de Janeiro de 2013, planeamos a continuação da elaboração em con-junto da descrição pormenorizada dos dois casos restantes. No entanto, concluimos que estesdois casos não cabiam dentro de um contexto da Web Semântica e foram eliminados. Eles nãotinham pertinência no contexto global de partilha de metadados mas sim num contexto particularde transferência de dados entre um cliente e um servidor de base de dados. Mais uma vez severificou que os analistas de sistemas não tinham conhecimentos de Web Semântica, querendoimpôr os conceitos dos modelos relacionais de base de dados. Desta reunião não saiu nenhumoutput para alimentar o artefacto Me4DCAP.

Na sexta reunião, a 5 de Fevereiro de 2013, planeamos a finalização da definição dos Casos--de-Uso de forma a definir de seguida os Requisitos Funcionais. Se houvesse ainda tempoplaneamos ainda elaborar o Modelo de Domínio, propondo a utilização da técnica UML para orepresentar. Na realidade na reunião: (i) discutiu-se o Documento Visão; (ii) os casos de uso.Desta reunião não saiu nenhum output para alimentar o artefacto Me4DCAP.

Na sétima reunião, 19 de Fevereiro de 2013, levamos a proposta de elaboração do modelode domínio, mas ainda não tinhamos os Requisitos Funcionais definidos. Um rascunho doModelo de Domínio foi elaborado por nós, e posto à discussão perante os elementos com perfil deespecialidade de domínio de aplicação.

Obtivemos os seguintes resultados da reunião para alimentar o artefacto Me4DCAP:• Foi utilizada a técnica UML por ser a técnica utilizada pelo Guia da DCMI e pelo DCAPSWAP. No entanto, esta ou qualquer outra técnica poderia ter sido usada porque oselementos do grupo que não tinham perfil técnico não entenderam a representação deimediato, foi necessário fazer uma explicação prévia.

• Achamos muito interessante a técnica ORM, ou a representação através gráficos de triplosRDF, porque se aproxima muito da lógica da modelação de dados para a codificação posteriorem DSP ou RDF; desta forma facilitaria a passagem para a codificação. Decidimos queesta técnica seria a utilizada no Modelo de Dados Detalhado.

A oitava reunião, a 7 de Março de 2013, foi uma reunião somente com a equipe técnica. Pla-neamos (i) discutir o Modelo de Domínio, aprofundando as propriedades de cada objecto; (ii)passar para a elaboração do Modelo de Dados Detalhado utilizando a técnica ORM. Concluimosque a partir deste momento só seria necessário a equipe alargada para validar o trabalho efectuadopela equipe técnica.

A nona reunião, a 9 de Abril de 2013, foi uma reunião de validação do Modelo de Dadosdetalhado, com um membro da equipe especialista de domínio. Além disso iniciou-se a construção



dos Guias de utilização. Ficaram responsáveis pela sua elaboração os especialistas de domínio. Omodelo foi discutido e modificações ficaram de ser pensadas pela equipe técnica. Desta reuniãonão saiu nenhum output para alimentar o artefacto Me4DCAP.

Na última reunião, a 5 de Fevereiro de 2014, a equipe técnica, com um dos elementos daequipe de trabalho com dois perfis (analista de sistemas - mas não desenvolvedor semântico -e especialista de domínio) reviu o modelo de dados detalhado e os Guias de Utilização. Comoresultado da reunião, como output para alimentar a concepção do artefacto Me4DCAP concluimosque a actividade de definição do modelo de dados detalhado é altamente iterativa.

4.3.2.1 Considerações finais

O trabalho desenvolvido com o grupo RIPESS, inicialmente apelidado de Consórcio e depois deESSGlobal, teve como resultado, à data da escrita desta Tese, uma versão que é apresentadano Capítulo 6 deste documento. No entanto, este trabalho ainda não está terminado; háefectivamente um conjunto de actividades que necessitam ainda de ser realizadas, tais como,definir os critérios de adequação, realizar o teste de adequação, realizar o teste em laboratório,desenvolver os guias de sintaxe e os guias de utilização. Contudo, há no momento presenteinteresse na incorporação do modelo de dados definido pelo DCAP-ESS num plug-in dos softwaresNoosfero22 e Wordpress23 que tenha a função de expor os metadados na WS.

4.4 Resumo do processo de construção do Método para o De-senvolvimento de Dublin Core Application Profiles

Como vimos, o processo de concepção do Me4DCAP tem um conjunto de actividades quenavegam entre diferentes Espaços, com objectivos específicos. Estas actividades têm um grandenível de interactividade entre elas. Nesta secção tentamos tornar este processo linear de forma aficar mais claro o caminho percorrido. A Figura 4.25 ajuda-nos a construir uma linha de percurso,tentando mostrar a forma como as actividades se foram sucedendo.

Podemos resumir a construção do Me4DCAP da seguinte forma :• o Me4DCAP é construído, na sua versão embrionária, a partir do “Estado da Arte dosmétodos de desenvolvimento de DCAP”, da recolha das “primeiras fases (até modelaçãode dados) dos métodos de desenvolvimento de software” e de informação recolhida a “trêsentrevistas realizadas a pessoas que desenvolveram DCAP” - actividades de RelevanceCycle e de Rigor Cycle;

• na “situação experimental”, em ciclos de construção e avaliação, o Me4DCAP é testadoe re-definido. Desse processo resulta uma primeira versão do Me4DCAP - actividades deDesign Cycle;

• essa versão é objecto de validação num grupo de discussão numa sessão paralela naconferência ElPub2013 - actividades de Relevance Cycle;

22Ver http://noosfero.org/ - acedido em 11 Fev 201423Ver https://wordpress.org/ - acedido em 18 Abril 2014


http://noosfero.org/

https://wordpress.org/


Figura 4.25: Percurso do desenvolvimento do Method for the Development of Dublin CoreApplication Profiles.

• dos resultados dessa sessão, conjuntamente com mais um momento de construção/reflexão,produz-se a segunda versão do Me4DCAP - actividades de Design Cycle;

• esta segunda versão é objecto de validação num FG realizado com especialistas de Metadados- actividades de Relevance Cycle;

• dos resultados do processo de validação, juntamente com mais um momento de reflexão-construção, produz-se a versão final do Me4DCAP - actividades de Design Cycle.

De notar que o desenho apresentado na Figura 4.25 não é uma linha do tempo. O eixo nahorizontal indica passagem de tempo mas não apresenta uma escala de tempo. De facto asactividades realizadas para estabelecer o estado da arte tomaram um peso de tempo diferente dasactividades de construção do método, com a situação experimental. Além disso as actividades devalidação tomaram outro tempo distinto também.

O processo ainda não está terminado. Na verdade projectamos a realização de field testingcomo trabalho futuro (actividades de Relevance Cycle), e esperamos que, dos resultados do fieldtesting, resulte a versão Me4DCAP V2.0 (actividades de Design Cycle).

No final do processo DSR, acontecerão ainda actividades de Rigor Cycle de teorização ejustificação. Estas actividades não aportarão nada de novo para o artefacto em si, mas darãorigor ao processo e contriuirão para a introdução de novas teorias à Knowledge Base, alargando oseu espectro.

4.5 Sumário

Este capítulo apresenta detalhadamente a aplicação da metodologia de investigação DSR noenquadramento dos três ciclos de Hevner (2007), no nosso projecto de investigação. O en-quadramento define a existência de três ciclos, em que cada um deles realiza um conjunto deactividades que actuam em espaços de trabalho bem definidos. Este capítulo detalha cada umadas actividades por nós realizadas nesses três ciclos. Todas estas actividades têm como objectivo



final a concepção do Me4DCAP.


Capítulo 5

Resultados - método para odesenvolvimento de um Dublin CoreApplication Profile

ARTKnowing the steps to create living growth, that is art.

Deng Ming-Dao

Este capítulo tem como objectivo a apresentação do Me4DCAP V0.1, resultado final destedoutoramento. A descrição do método desenrola-se tendo em mente a necessidade de apresentaras formas de modelação, de trabalho e de controlo que, segundo Wijers (1991), um métododeve ter. Tendo como objectivo o desenvolvimento dos deliverables definidos no Enquadramentode Singapura, a descrição do método é realizada através da: (i) apresentação das actividadesque o compõem, e da forma como elas se interligam; (ii) sugestão de técnicas para realizar asactividades definidas, e ainda; (iii) definição do perfil das pessoas que devem compor a equipe detrabalho do desenvolvimento, e onde elas devem intervir.

5.1 Introdução

Este capítulo tem como objectivo a apresentação do trabalho final deste projecto de doutoramento:um contributo para o enquadramento metodológico do desenvolvimento de DCAP. Como jáfoi dito anteriormente não se pretende propôr uma solução universal, mas antes um ponto departida para o estudo e desenvolvimento desta problemática no seio de diferentes comunidadesde metadados.

Como referido no capítulo 2, o constructo DCAP está definido no Enquadramento de Singapura(c.f. Baker et al. (2008)) e no guia da DCMI (c.f. Baker and Coyle (2009)). Este documentosdefinem o desenvolvimento de um DCAP como um processo que deverá produzir os seguintesdeliverables:

• Requisitos Funcionais (obrigatório);

99

5. Resultados - método para o desenvolvimento de um Dublin Core Application Profile

• Modelo de Domínio (obrigatório);• Description Set Profile (obrigatório);• Guias de Utilização (não obrigatório);• Guias de Sintaxe (não obrigatório).O Enquadramento de Singapura confunde o conceito de actividade com o de deliverable. Por

respeito a este documento, tão importante na comunidade de metadados, vamos seguir as suasorientações, tentando lidar com este problema. Para isso definimos as Etapas de Singapura comosendo: Desenvolver os Requisitos Funcionais, Desenvolver o Modelo de Domínio, Desenvolvero DSP, Desenvolver os Guias de Utilização e Desenvolver os Guias de Sintaxe. Estas Etapasde Singapura produzem, quando completadas, os deliverables de singapura já referidos (c.f.Figura 5.1). As Etapas de Singapura serão decompostas em sub-actividades.

Figura 5.1: As etapas de singapura e os respectivos deliverables

O Me4DCAP define o caminho a seguir ao longo do tempo no processo estabelecendo:• quais as actividades necessárias realizar;• quando devem ser estas actividades executadas;• como estão interligadas;• que artefactos estas actividades produzem.O Me4DCAP por vezes sugere ainda que técnicas utilizar no exercício dessas actividades.O desenvolvimento de um DCAP é portanto um processo por etapas, sendo cada etapa

construída a partir dos resultados da etapa anterior (c.f Figura 2.2). Este conjunto de etapas é o



nosso ponto de partida para a definição do Me4DCAP. O Me4DCAP apresenta as actividadesnecessárias para produzir os deliverables de Singapura.

A Figura 5.2 apresenta o encadeamento de todas as actividades do Me4DCAP. Estasactividades são apresentadas nas secções seguintes, onde descrevemos as Etapas de Singapura:

• Desenvolver os Requisitos Funcionais na secção 5.3;• Desenvolver o Modelo de Domínio na secção 5.4;• Desenvolver os Guias de Utilização na secção 5.6;• Desenvolver os Guias de Sintaxe na secção 5.7;• Desenvolver o Description Set Profile na secção 5.5.O flow destas actividades é apresentado recorrendo a diagramas de actividades UML. Estes

diagramas têm dois níveis: (i) o diagrama de contexto; (ii) o diagrama de actividades - nível 1que pormenoriza as actividades compostas dos diagramas de contexto. Uma actividade compostaé uma actividade que possui sub-actividades. Para facilitar a leitura, as actividades compostasestão marcadas com um “*”. Os deliverables de Singapura estão referidos à frente da actividadeque os desenvolve através de uma caixa preenchida a uma côr. A côr mais intensa indica osdeliverables obrigatórios, a menos intensa os facultativos.

O ciclo de vida do Me4DCAP segue o modelo evolutivo porque a qualquer momento a equipede trabalho pode voltar atrás no processo de desenvolvimento para verificar de novo os artefactosdesenvolvidos. O processo de desenvolvimento pode saltar actividades, ou continuar o ciclode vida segundo a ordem indicada, dependendo das mudanças efectuadas nos artefactos: seinfluenciam outros artefactos, eles devem passar por um processo de re-verificação. Trata-seportanto de um processo bastante iterativo. O número de iterações depende da dimensão ecomplexidade do DCAP em desenvolvimento. As iterações terminam quando não houver nadapara “descobrir” ou acrescentar, dependendo dos resultados das actividades de validação emlaboratório ou de validação em produção (c.f. Secção 5.5 para saber mais sobre estas validações).

O Me4DCAP foi definido em quatro fases (c.f. Figura 5.3) (colunas da figura): Definiçãode Âmbito, Construção, Desenvolvimento e Validação. Estas fases são atravessadas (linhas dafigura) ao longo do projecto pelas actividades que desenvolvem os deliverables de Singapura. Nafase de “Definição de Âmbito” inicia-se o planeamento dos trabalhos; ela tem como objectivodefinir o âmbito de aplicação do DCAP, organizar a equipe de trabalho e realizar o estudo docontexto de aplicação do DCAP. Nesta fase desenvolvem-se portanto parte das actividades daEtapa de Singapura Desenvolver os Requisitos Funcionais. No entanto este desenvolvimento nãoé estanque a esta fase transbordando para a fase seguinte, a fase de “Construção”. Na fase de“Construção” continua-se com as actividades incluídas na Etapa de Singapura Desenvolver osRequisitos Funcionais, e desenvolve-se ainda a Etapa de Singapura Desenvolver o Modelo deDomínio. No entanto ela não é, à semelhança do caso anterior, estanque a esta fase, e transbordapara a fase seguinte, a fase de “Desenvolvimento”. A fase de “Desenvolvimento” é o culminar detoda a construção efectuada até ao momento. Nesta fase desenvolve-se a Etapa de SingapuraDesenvolver o DSP, que só acontece depois de grande parte das Etapas de Singapura Desenvolveros Requisitos Funcionais e Desenvolver o Modelo de Domínio estarem concluídas. A Etapa deSingapura Desenvolver o DSP continua na fase “Validação”, onde se realizam as actividades de



validação do DCAP (em laboratório e em produção) e desenvolvimento do DSP. As Etapas deSingapura Desenvolver os Guias de Utilização e Desenvolver os Guias de Sintaxe são desenvolvidasprincipalmente ao longo da fase de “Desenvolvimento”. Rectificações podem ser feitas aos Guiasdurante a fase de “Validação”.

5.2 A equipe de trabalho de desenvolvimento do Dublin CoreApplication Profile

O Me4DCAP define os seguintes tipos de função-perfil mínimos para a equipe de trabalho dedesenvolvimento de um DCAP:Gestor de Projecto

O Gestor de Projecto “assume a visão global do projecto através de uma interacçãodetalhada com os participantes internos e externos” (Borges et al., 2012, p. 63). Deverá seralguém que pertence às organizações que estão empenhadas no desenvolvimento do DCAP.Deverá ter uma visão do âmbito da Organização e do objectivo que pretende alcançar como desenvolvimento do DCAP.

Analista de SistemasO Analista de Sistemas deverá ter conhecimentos em duas vertentes: (i) competênciastécnicas em elicitação de requisitos e em modelação de dados; (ii) “conhecimentos básicosde gestão”, comprender em detalhe o domínio de aplicação e ainda entender “a motivaçãoreal e a relevância dos requisitos” (Borges et al., 2012, p. 62).

Desenvolvedor SemânticoO desenvolvedor semântico deverá ser um desenvolvedor/desenhador de metadados quecompreende os conceitos da Web Semântica e que tem conhecimentos técnicos em DSP eRDF.

Editor TécnicoO Editor Técnico é alguém que irá desenvolver a documentação do DCAP e que deverá tercompetências em escrita técnica e conhecimento do contexto de aplicação do DCAP.

Especialista no Domínio de AplicaçãoUm Especialista no Domínio de Aplicação deverá ser um especialista no contexto deaplicação do DCAP em desenvolvimento.

Utilizador FinalHá potencialmente vários tipos de Utilizadores Finais que incluem os programadores deaplicações que fazem uso do DCAP, as pessoas que alimentam o sistema, as pessoas queconsomem informação do sistema e ainda automata em geral, executando a função dedescoberta no paradigma da WS.



Figura 5.2: A interligação das actividades do Method for the Development of Dublin Core Application Profiles V1.0.



Figura 5.3: As fases do Method for the Development of Dublin Core Application Profiles V1.0.

A equipe de trabalho é então composta por um conjunto de pessoas onde um perfil pode serpartilhado por várias pessoas, e a mesma equipe pode ter várias pessoas com o mesmo perfil,dependendo da dimensão do trabalho. Sendo grande parte do desenvolvimento de um DCAPum trabalho técnico, para equipes grandes, o Me4DCAP define uma “Equipe Técnica” que écomposta pelos perfis mais técnicos: o Analista de Sistemas e o Desenvolvedor Semântico; euma “Equipe Alargada” que é composta pelos restantes perfis. Neste caso, em determinadosmomentos do processo de desenvolvimento, a equipe técnica é responsável pelos trabalhos; aequipe alargada valida sempre o trabalho realizado pela equipe técnica. É muito importante quea equipe de trabalho seja multidisciplinar e isso deve ser respeitado para o sucesso dos trabalhos.

Em processos de desenvolvimento de DCAP é comum a equipe de trabalho estar separadageograficamente e por isso devem ser definidas ferramentas colaborativas assim como as regraspara a sua utilização. Estas ferramentas podem ser: audio/vídeo1 para efectuar reuniões adistância, Wiki2 ou qualquer outra ferramenta3 para registar pensamentos e reflexões de umaforma colaborativa.

As secções seguintes descrevem cada Etapa de Singapura do Me4DCAP: em que actividadesconsistem e quais os perfis da equipe de trabalho que são responsáveis por desenvolve-las; queartefactos essas actividades devem produzir e quais as técnicas que podem ser utilizadas para osdesenvolver.

1Ex: Skype.2Ex: software DokuWiki - http://dokuwiki.org - acedido em 17 Nov 2013.3Ex: PONTAOPAD para registo das reuniões - http://www.pontaopad.me - acedido em 20 Nov 2013.


http://dokuwiki.org

http://www.pontaopad.me


5.3 Desenvolver os Requisitos Funcionais

Há duas actividades que acompanham todo o desenvolvimento do DCAP - c.f. Figura 5.2. Elassão:

• Desenvolver o Glossário;• Desenvolver a Documentação do DCAP.A actividade Desenvolver o Glossário é uma actividade muito importante no caso de equipes

de trabalho compostas por pessoas de diferentes contextos. O Glossário é um documento detexto com as palavra-chave e sua descrição, utilizadas no desenvolvimento do DCAP. Ele éusado para definir termos importantes e comumente usados pela equipe de trabalho quandodefinem o DCAP. É importante o seu desenvolvimento para que todos os elementos da equipefalem um idioma comum porque evita mal-entendidos e melhora a comunicação Jacobson et al.(1999). Todos os elementos da equipe devem contribuir para o desenvolvimento do glossário.Esta actividade produz o artefacto Glossário.

A actividade Desenvolver a documentação do DCAP consiste no registo de todos os resultadosdo processo de desenvolvimento e ainda no registo da justificação das opções tomadas no processo.A documentação de qualquer processo de desenvolvimento é fundamental; a existência dedocumentação ajuda os utilizadores finais da aplicação do DCAP a aplicar correctamente oDCAP à sua situação particular, e assegura ainda que futuros desenvolvedores entendam oprocesso do desenvolvimento do DCAP. Esta actividade produz o artefacto Documentação doDCAP.

A Etapa de Singapura Desenvolver os Requisitos Funcionais é decomposta em seis actividades(c.f. Figura 5.4 com o diagrama de contexto desta Etapa de Singapura):

• Definir a Visão;• Definir o Plano de Trabalho;• Definir o Domínio de Aplicação;• Definir os Requisitos de Alto-nível;• Desenvolver o Modelo dos Casos-de-Uso (actividade composta);• Definir os Requisitos Funcionais.Se a equipe de trabalho tiver acesso a documentação sobre a descrição dos recursos ou acesso

aos modelos de dados de sistemas de informação existentes, será possível recorrer à técnicade Análise de Documentação para desenvolver os requisitos funcionais. Nesse caso não seránecessário desenvolver as actividades Definir os Requisitos de Alto-Nível nem Definir o Modelode Casos-de-Uso.

A actividade Definir a Visão consiste em definir o âmbito do DCAP, mostrando os limites dasua utilização. Trata-se de realizar um documento simples de texto com cerca de 200 palavras,descrevendo os limites da utilização do DCAP e informando sobre o que a equipe de trabalho queratingir com o desenvolvimento do DCAP. A técnica utilizada para desenvolver esta actividadepoderá ser a técnica de brainstorming onde todos os elementos da equipe estão livres de escreverideias num quadro (seja ele real ou na Web, consoante a distribuição geográfica da equipe e asua possibilidade de se reunir numa mesma sala), seguido de uma discussão. No final, o conjunto



Figura 5.4: Diagrama de contexto da Etapa de Singapura: Desenvolver os Requisitos Funcionais.

de ideias deverá ser organizado em pequenas frases. O artefacto produzido corresponde aoDocumento Visão. O grupo é liderado pelo Gestor de Projecto; todos os elementos da equipe detrabalho deverão trabalhar nesta actividade.

Duas situações podem acontecer em relação à actividade Definir a Visão:

• por um lado ela pode não acontecer caso a visão seja definida pela equipe de gestão quedecide a criação de uma equipe de trabalho para o desenvolvimento de um DCAP:

• por outro lado, caso o esforço de desenvolvimento do DCAP seja partilhado por váriasorganizações, há uma grande probabilidade de que a visão seja definida pela equipe detrabalho de desenvolvimento do DCAP.

Terminada a definição do Documento Visão, as actividades seguintes, realizadas em simultâneo,são Definir o Plano de Trabalho e Definir o Domínio de Aplicação.

A actividade de Definir o Plano de Trabalho tem como objectivo o planeamento temporaldas actividades do projecto; é o seguimento do tempo do projecto e serve como um guia para aequipe de trabalho do projecto de desenvolvimento do DCAP. O Plano de Trabalho refere ostempos de cada fase, com as respectivas datas de início e de fim, e ainda as datas em que cadaEtapa deverá estar terminada. O plano de trabalho poderá ainda conter informação sobre as



responsabilidades que cada elemento da equipe de trabalho tem na fase ou na actividade emquestão. O Plano de Trabalho pode ser uma folha de texto com um gráfico de Gantt, ou qualqueroutro tipo de gráfico ou esquema que a equipe de trabalho envolvida no projecto ache maisconveniente. Esta actividade deverá ser realizada por todos os membros da equipa, liderados peloGestor de Projecto; deverão negociar entre eles de forma a encaixar todas as agendas. No final oartefacto produzido corresponde ao Plano de Trabalho. Aceita-se que o Plano de Trabalho sejamodificado ao longo do tempo à medida que o projecto evolua.

A actividade Determinar o Domínio de Aplicação” do DCAP tem como objectivo: (i) acompreensão do contexto em que se insere o DCAP - compreensão sobretudo por parte doselementos da Equipe Técnica e; (ii) a definição de limites da aplicação. Eles deverão terconhecimento do contexto para poderem definir correctamente cada termo do DCAP. Estaactividade resume-se à elaboração do estado da arte do contexto onde estão definidos os principaisconceitos do contexto de aplicação, interligados entre si. Este documento de texto deverá serelaborado por toda a equipe de trabalho, liderada pelo Especialista no Domínio de Aplicação. Oartefacto produzido corresponde ao Estado da Arte do Contexto de Aplicação.

Uma vez terminadas as actividades Definir o Plano de Trabalho e Definir o Domínio deAplicação, segue-se a actividade de Definir os Requisitos de Alto-nível. Esta actividade tratade definir a lista dos requisitos funcionais e não-funcionais expressos pela equipe de trabalho,especialmente pelos perfis Utilizador Final e Gestor de Projecto. Esta lista é uma descriçãomuito curta, não mais do que duas linhas por requisito; esta lista será detalhada mais à frenteno processo, aquando da actividade de desenvolvimento do diagrama UML de casos-de-uso. Aequipe de trabalho pode usar a mesma técnica utilizada na actividade de definição do DocumentoVisão. Esta actividade é liderada pelo Analista de Sistemas e toda a equipe deve participar nela.No final o artefacto produzido corresponde aos Requisitos de Alto-nível.

Sendo o workflow do Me4DCAP evolutivo, haverá momentos em que a equipe de trabalhodeverá libertar algum artefacto na sua versão rascunho para progredir nos trabalhos, podendomais tarde voltar a actividades anteriores para redefinir ou melhorar os artefactos rascunhoentretanto libertados.

Terminada a definição dos Requisitos de Alto-nível segue-se a actividade composta Desenvolvero Modelo de Casos-de-Uso. Ela é decomposta em duas sub-actividades, realizadas em simultâneo(c.f. Figura 5.5 para o diagrama de actividades - nível 1):

• Desenvolver o Diagrama UML de Casos-de-Uso;• Desenvolver os Casos-de-Uso Detalhados.Os casos-de-uso são uma técnica específica que oferece “uma forma sistemática e intuitiva de

capturar requisitos funcionais” (Jacobson et al., 1999, p. 37). “Cada caso-de-uso inclui detalhessobre o que é preciso fazer para atingir a sua funcionalidade” (Schneider and Winters, 2001,p. 27). Os casos-de-uso serão usados para desenvolver os requisitos funcionais e para entender osobjectos (e suas propriedades) do sistema em estudo.

Um Diagrama UML de Casos-de-Uso descreve a funcionalidade do sistema em definição,indicando os actores que interagem com o sistema. Para obter informação de como construir umdiagrama UML de casos-de-uso consultar Fowler (2004) ou Jacobson et al. (1999). A actividade



Figura 5.5: Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Modelo deCasos-de-Uso.

Desenvolver o Diagram UML de Casos-de-Uso deverá ser realizada pelo Analista de Sistemas.O artefacto final Diagrama UML de Casos-de-Uso deverá ser validado por toda a equipe detrabalho.

A actividade Desenvolver os Casos-de-Uso Detalhados, detalha cada caso-de-uso definidono artefacto Diagrama UML de Casos-de-Uso. Esta documentação deverá definir a sequênciade acções - uma sequência específica de eventos que acontecem no sistema - que o sistemarealiza para trazer valor acrescentado a determinado actor. Um actor é alguém ou alguma coisa(automata) fora do sistema que interage com ele Kruchten (2004). O detalhe dos casos-de-uso éuma descrição do fluir dos eventos e deverá ser efectuado utilizando o modelo que Schneider andWinters (2001) propõem e a definição de caso-de-uso existente no Glossário (c.f. Secção 5.2).Esta actividade Desenvolver os Casos-de-Uso Detalhados deverá ser realizada por toda a equipede trabalho, liderada pelo Analista de Sistemas. No final, o artefacto produzido corresponde aosCasos-de-Uso Detalhados.

A última actividade da Etapa de Singapura é Desenvolver os Requisitos Funcionais. Osartefactos até aqui desenvolvidos servirão de suporte para a identificação desses requisitos. Osrequisitos funcionais “guiam o desenvolvimento do perfil de aplicação fornecendo objectivos elimites e são um componente essencial para o sucesso do processo de desenvolvimento de umperfil de aplicação. Este desenvolvimento é uma tarefa de uma ampla comunidade que podeenvolver gestores de serviços, especialistas dos materiais a ser utilizados, pessoas que desenvolvemaplicações e potenciais utilizadores finais dos serviços.” Baker and Coyle (2009). O documentoque define os Requisitos Funcionais é um documento de texto, com a referência a objectivos finaise a tarefas específicas Baker and Coyle (2009). Para desenvolver esta actividade, os elementos daequipe deverão analisar em grupo os Casos-de-Uso e identificar quais os requisitos funcionais aíexplicitados. Para os descrever, deverão usar pequenas frases e escrevê-las num quadro (seja elereal ou na Web, consoante a distribuição geográfica da equipe e a sua possibilidade de se reunirnuma mesma sala). Depois disso, o trabalho poderá ser distribuído por cada membro da equipede trabalho que deverá ficar responsável por uma ou mais ideias-frase de forma a desenvolver otexto. No final a equipe deverá reunir-se, e discutir e aprovar o resultado final. É importanteidentificar as funcionalidades que são obrigatórias e as que não são. É também importanterealizar uma verificação cruzada dos Requisitos Funcionais com os Casos-de-Uso Detalhados. O



Analista de Sistemas lidera esta actividade, ela fornece como resultado o deliverable RequisitosFuncionais.

5.4 Desenvolver o Modelo de Domínio

A Etapa de Singapura Desenvolver o Modelo de Domínio (c.f. Figura 5.6 com o diagrama decontexto desta Etapa de Singapura) é decomposta em duas actividades que se efectuam emsimultâneo:

• Realizar o Environmental Scan;• Defnir o Modelo de Domínio.

Figura 5.6: Diagrama de contexto da Etapa de Singapura: Desenvolver o Modelo de Domínio

A actividade Realizar o Environmental Scan consiste em realizar o relatório do estado daarte dos esquemas de metadados existentes que estão codificados em RDF e que possam serviras necessidades do deliverable Modelo de Domínio em definição. O artefacto Environmental Scandeverá ser realizado pelo Desenvolvedor Semântico. O Desenvolvedor Semântico poderá recorrerda ajuda de sistemas de registo em linha tais como, por exemplo: o Open Metadata Registry4, oLinked Open Vocabularies (LOV)5, o Basel Register of Thesauri, Ontologies & Classifications(BARTOC)6 entre outros7.

A actividade de Definir o Modelo de Domínio é realizada através da captura dos “tipos deobjectos mais importantes no contexto do sistema.” (Jacobson et al., 1999, p. 119). SegundoBaker and Coyle (2009) “o modelo de domínio é a descrição das coisas que os metadados irãodescrever, e das relações entre essas coisas. O modelo de domínio é o projecto base para aconstrução do perfil de aplicação”. Ele identifica as classes de objectos e suas relações. Osatributos dos objectos deverão ser omitidos uma vez que não é necessário nesta fase dos trabalhos

4Ver http://metadataregistry.org/ - Acedido em 20Nov2013.5Ver http://lov.okfn.org/dataset/lov/ - acedido em 13Nov2013.6Ver http://www.bartoc.org/ - acedido em 13Nov2013.7Existe investigação em curso na comunidade de metadados com o objectivo de desenvolver ferramentas que

ajudem os desenvolvedores de DCAP nesta tarefa, no futuro - c.f. da Silva et al. (2012).


http://metadataregistry.org/

http://lov.okfn.org/dataset/lov/

http://www.bartoc.org/


detalhá-los, serão detalhados mais à frente na actividade de desenvolvimento do modelo de dadosdetalhado (c.f. Secção 5.5). É importante que o Modelo de Domínio seja facilmente extensível deforma a ser simples a integração de desenvolvimentos futuros. O modelo de Domínio deverá serconstruído a partir do deliverable Requisitos Funcionais e do artefacto Modelo de Casos-de-Uso8.Nas situações em que haja acesso a documentação que descreva os recursos ou acesso a base dedados dos sistema de informação, é possível recorrer à técnica de Análise Documental para odefinir.

O Me4DCAP sugere que o Modelo de Domínio seja desenvolvido com uma técnica gráfica(por exemplo ORM - c.f. Nijssen and Halpin (1989) e Halpin (2006) para mais informação sobrediagramas ORM e Halpin and Morgan (2010) para modelação ORM e a Web Semântica; ER -c.f. Chen (1976) para mais informação sobre diagramas ER ou UML - c.f. Fowler (2004) paramais informação sobre diagramas UML). A técnica a utilizar deverá ser aquela que a equipe detrabalho entender ser a mais adequada para toda a equipe e não somente para a equipe técnica.

A actividade Definir o Modelo de Domínio resulta no deliverable Modelo de Domínio; eleé definido pela equipe técnica. A sua versão final deverá ser discutida e validada pela equipealargada.

5.5 Desenvolver o Description Set Profile

A Etapa de Singapura Desenvolver o DSP (c.f. Figura 5.7 com o diagrama de contexto destaEtapa de Singapura) é decomposta em cinco actividades:

• Desenvolver o Pré-Description Set Profile (actividade composta);• Definir os Critérios de Adequação;• Realizar a Validação em Laboratório (actividade composta);• Codificar o DSP;A actividade composta Desenvolver o pré-Description Set Profile (Pré-DSP) e a actividade

Definir os Critérios de Adequação podem ser realizadas em simultâneo.A actividade Desenvolver o pré-DSP é decomposta em três sub-actividades (ver o diagrama

de actividades - nível 1 na Figura 5.8):• Desenvolver o Modelo de Dados Detalhado;• Desenvolver o Alinhamento de Vocabulários;• Definir a Matriz de Restrições.A actividade Desenvolver o Modelo de Dados Detalhado consiste na identificação das pro-

priedades dos objectos das classes do domínio identificadas no deliverable Modelo de Domínio(desenvolvido na Etapa anterior). Para além disso deverá referir, para cada propriedade, se é ounão obrigatória, a sua repetibilidade, a sua codificação e a possibilidade de ser multi-idioma. Estaactividade produz o artefacto Modelo de Dados Detalhado. O Me4DCAP sugere a utilização deuma técnica gráfica para representar o Modelo de Dados Detalhado9. Este artefacto deverá serdesenvolvido pela equipe técnica, e discutido e validado pela equipe alargada.

8Descritos na Secção 5.39Os mesmos exemplos fornecidos no Modelo de Domínio - c.f. Secção 5.4



Figura 5.7: Diagrama de contexto da Etapa de Singapura: Desenvolver o Description Set Profile

A actividade Desenvolver o Alinhamento de Vocabulários consiste em identificar os termosdos esquemas de metadados existentes no artefacto Environmental Scan, e ainda os SES eVES, que estão codificados em RDF e que sirvam as necessidades do artefacto Modelo deDados Detalhado. No momento de desenvolvimento deste artefacto ainda não era claro para oDesenvolvedor Semântico o deliverable Modelo de Domínio, e muito menos o artefacto Modelo deDados Detalhado. Nessa altura o Desenvolvedor Semântico oscultou a comunidade de metadadossobre os esquemas de metadados existentes que pudessem servir as necessidades do DCAP.Neste momento de desenvolver o alinhamento de vocabulários, estando já o artefacto Modelode Dados Detalhado desenvolvido, o Desenvolvedor Semântico possui mais pormenores sobre asnecessidades do DCAP. Poderá, portanto, restringir o Environmental Scan a um sub-conjunto deinformação mais apropriado ao Modelo de Dados Detalhado disponível. Esta actividade produz oartefacto “Alinhamento de Vocabulários”; ele será utilizado, juntamente com o Modelo de DadosDetalhado, na actividade seguinte, de desenvolvimento da matriz de restrições. O responsávelpelo desenvolvimento do alinhamento de vocabulários é o Desenvolvedor Semântico.

A actividade Definir a Matriz de Restrições consiste na definição de uma matriz onde, porlinha, cada atributo e respectivas restrições são descritos pelas propriedades dos esquemasde metadados e esquemas de codificação definidos no artefacto Alinhamento de Vocabulários(definido na actividade anterior). No caso de não existirem termos nos esquemas de metadadosno artefacto Alinhamento de Vocabulários para definir algumas das propriedades do modelo dedados detalhado ou para definir as restrições necessárias, novas propriedades, SES ou VES devem



Figura 5.8: Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Pré-Des-cription Set Profile

ser criados para que a matriz não fique incompleta10. A actividade Definir a Matriz de Restriçõesresulta no artefacto Matriz de Restrições. Uma proposta de modelo de Matriz de Restrições,baseada na proposta dos Guias da DCMI de Baker & Coyle (2009), é apresentada na Figura 5.9.

Figura 5.9: Proposta de modelo da Matriz de Restrições (baseada em Baker and Coyle (2009)).

Esta matriz tem duas tabelas:• A primeira tabela, Definition of Namespaces used, define os Namespaces usados:

– Title: O título do Namespace (e.g. Dublin Core Metadata Initiative Terms).– Full Namespace URI : O URI que identifica o Namespace (e.g. http://www.purl.org/dc/terms

10É interessante referir que outras ferramentas em linha surgem, de apoio ao desenvolvimento de ferramentaspara a Web Semântica. Recentemente - Janeiro 2014 - foi criada uma ferramenta para a realização de testes decontrolo de qualidade a VES que estejam desenvolvidos em SKOS: http://qskos.poolparty.biz/ - acedido em23 Janeiro 2014.


http://qskos.poolparty.biz/


or http://www.w3.org/ns/org/).– Prefix: O prefixo usado (e.g dcterms).

• A segunda tabela, Definition of Description Templates, com um quadro por cada DescriptionTemplate existente, define as propriedades (e as possíveis restrições) de cada um dosDescription Templates:

– na primeira linha de cada Description Template:

∗ Description Template: O nome da classe.∗ Property: O esquema de metadados ou vocabulário, e respectivo termo utilizado(e.g. org:Organization).

∗ Usage: Uma descrição breve do que a classe representa na vida real.

– na segunda linha de cada Description Template, referente a cada propriedade doDescription Template a ser definido:

∗ Label: A etiqueta dada à propriedade.∗ Property: O Esquema de Metadados ou Vocabulário, e respectivo termo utilizado(e.g. dcterms: title).

∗ Range: O contra-domínio da propriedade: definir se o seu valor é um “literal” ouum “non-literal”.

∗ Value String: No caso do contra-domínio ser um Value String, preencher com“Sim”, caso contrário, preencher com “Não”.

∗ SES URI : No caso da propriedade ter um formato específico. Indicar o URI desseSES.

∗ Value URI : No caso do contra-domínio estar restrito a um Value URI, preenchercom “Sim”, caso contrário, preencher com “Não”.

∗ VES URI : No caso do contra-domínio estar restrito a um VES, indicar o URI.∗ Related Description: No caso da possibilidade de a propriedade ser descrita poroutras propriedades (e.g. um autor poderá ter como definição o email, o nome,o sobrenome, etc.). Caso isso aconteça, preencher com “Sim” caso contrário,preencher com “Não”.

∗ Min: O mínimo número de vezes que a propriedade pode ser repetida.∗ Max: O máximo número de vezes que a propriedade pode ser repetida.∗ Usage: Uma descrição breve do que a propriedade representa na vida real.

O responsável pelo desenvolvimento do artefacto Matriz de Restrições e pela criação de novostermos é o Desenvolvedor Semântico.

A actividade de Definir os Critérios de Adequação, a ser realizada em simultâneo com odesenvolvimento da actividade composta Desenvolver o Pré-DSP, consiste em definir a forma detestar se o DCAP desenvolvido responde às funcionalidades obrigatórias definidas no deliverableRequisitos Funcionais. Esta actividade produz o artefacto Critérios de Adequação. Ele deve serdesenvolvido por toda a equipe de trabalho, sendo o responsável o Desenvolvedor Semântico.



Neste ponto terminam as actividades de Desenvolver o Pré-DSP e de Definir os Critérios deAdequação.

A actividade seguinte corresponde à realização da actividade composta Realizar a Validaçãoem Laboratório. Esta actividade composta é decomposta em três sub-actividades (ver o diagramade actividades - nível 1 na Figura 5.10):

• Realizar o Teste de Adequação;• Realizar o Teste em Laboratório;• Realizar o Questionário.

Figura 5.10: Diagrama de actividades - nível 1 da actividade composta: Desenvolver a Validaçãoem Laboratório.

Uma validação em laboratório deverá ser efectuada para verificar:• a adequação do DCAP, através da actividade Realizar o Teste de Adequação. Esta

actividade consiste em efectuar uma reunião com todos os elementos da equipe de trabalhopara avaliar a resposta do DCAP aos critérios definidos no artefacto Critérios de Adequação.A equipe de trabalho deverá verificar os pontos definidos nesse artefacto - esse trabalhoficará registado no artefacto Teste de Adequação;

• se o DCAP está adaptado aos recursos que irão ser descritos por ele, através da actividadeRealizar o Teste em Laboratório. Esta actividade realiza-se em dois tempos:1. Aplica-se o DCAP a uma amostra de recursos seleccionada pela equipe de trabalho

ou por especialistas nos materiais a serem utilizados pelo DCAP. Depois disso, oUtilizador Final, ajudado pelo Desenvolvedor Semântico, deverá definir cada recursonum artefacto que se chamará de Teste em Laboratório, trata-se efectivamente derealizar uma instanciação do DCAP. Este trabalho deverá ser realizado com o apoiodos deliverables Guias de Utilização e Guias de Sintaxe, entretanto desenvolvidos(c.f. Secção 5.6 e Secção 5.7). Uma proposta de modelo de Teste em Laboratório éapresentado na Figura 5.11. Cada recurso é descrito através das classes e respectivaspropriedades definidas no artefacto Matriz de Restrições; por recurso existirão tantasclasses quantas as definidas nessa Matriz:



– No “Recurso 1“ (Resource 1 ), na “Classe 1” (Class 1 ), deverá escrever-se o nomeda primeira classe descrita na Matriz de Restrições. Em “Classe 2” (Class 2 ), onome da segunda classe descrita na Matriz de Restrições, e assim sucessivamenteaté não haver mais classes definidas na Matriz de Restrições;

– Em “Propriedade 1” (Property 1 ) (da “Classe 1”, “Recurso 1“) deverá escrever-sea etiqueta referente à primeira propriedade da Classe 1 do Recurso 1, definidana Matriz de Restrições, de seguida indicar o valor que o Recurso em questãotem nessa Classe/Propriedade; Em “Propriedade 2” (Property 2 ) (da “Classe1”, “Recurso 1“) deverá escrever-se a etiqueta referente à segunda propriedadeda Classe 1 definida na Matriz de Restrições, e de seguida indicar o valor queo Recurso em questão tem nessa Classe/Propriedade. E assim sucessivamenteaté não haver mais propriedades na Classe 1 a serem descritas, passando-se paraa Classe seguinte, até não haver mais Classes a serem descritas no recurso emquestão, passando-se para o recurso seguinte, terminado quando não houver maisrecursos a serem descritos;

– Deve indicar-se o URI do ficheiro onde cada Classe está definida no campo “Link”em frente a cada Classe.

2. Para terminar a actividade Realizar a Validação em Laboratório, segue-se a actividadeRealizar um Questionário. Os elementos da equipe que realizaram o Teste em Labora-tório deverão responder a um conjunto de questões de forma a avaliar as dificuldadesobtidas no processo de validação. O objectivo é o de avaliar: (i) se existem dados paraos quais o DCAP não previu descrição; (ii) se há termos definidos no DCAP que nãoestão adequados aos recursos; (iii) se os VES e SES, os domínios e contra-domínios sãoadequados aos recursos; (iv) outro tipo de dificuldade ou ambiguidade. Em suma, setodas as células da Matriz de Restrições estão adequadas aos recursos. As perguntaspoderão ser do tipo :– Foi possível descrever os seus recursos com os elementos disponíveis? Se não,

pode por favor descrever as dificuldades que teve?– Aconteceu ter termos que ficaram por preencher? Quais? Isso aconteceu porque

não tinha mesmo informação ou porque não sabia como o fazer?– Teve alguma outra dificuldade em descrever os recursos? Houve ambiguidades?– Há mais alguma coisa que deseje referir?

Esta actividade produz o artefacto Questionário. O responsável pela actividade devalidação em laboratório é o Desenvolvedor Semântico.De acordo com os resultados desta validação, o processo itera ou segue. Emborajá tenhamos referido a iteratividade de todo o processo de desenvolvimento de umDCAP, é de facto no momento da validação em laboratório que o processo iterativo émais intenso.

Uma vez terminada a actividade de Realizar a Validação em Laboratório é possível seguirpara a actividade de Codificação do DSP. O Desenvolvedor Semântico deverá descrever emdetalhe o DCAP utilizando a linguagem de codificação DSP definida por Nilsson (2008), tendo



Figura 5.11: Proposta de modelo de documento de Teste em Laboratório

como suporte o artefacto Matriz de Restrições. Esta actividade resulta no deliverable DSP.Para obter mais informação sobre a linguagem de codificação DSP, incluindo exemplos de

implementação, consultar o recurso Baker and Coyle (2009)11.A actividade Realizar a Validação em Produção (c.f. Figura 5.2), a realizar no final de todo

processo de desenvolvimento, pode estar fora do âmbito do desenvolvimento do DCAP. A equipede trabalho deverá decidir se está dentro dos seus objectivos ou não fazê-la. Esta actividadevalida em produção o DCAP, e pode ser realizada utilizando uma técnica de registo de logs oude observação de utilizadores finais a trabalhar com o sistema que implementou o DCAP. Oresultado final é um relatório com as considerações sobre as alterações necessárias ao DCAP.

Todo este trabalho deverá ser realizado pelo Desenvolvedor Semântico: recolha das informaçõesnecessárias e relatório. O relatório deverá ser entregue à equipe de trabalho de forma a que estareveja as definições do DCAP. Se existir nova informação pertinente a introduzir no DCAP,todos os artefactos e deliverables definidos para o DCAP devem ser revistos.

Tendo as aplicações da WS muitas interacções e muitas implicações noutros sistemas, aimplementação das alterações do DCAP é uma tarefa muito delicada. Os utilizadores do DCAP

11Uma nova ferramenta aparece na comunidade de metadados para permitir a criação de modelos de formuláriosRDF formulator. O RDFForms - c.f https://bitbucket.org/metasolutions/rdforms/overview; acedido em 21Março 2014 - é um software que permite, a partir de uma interface gráfica, a definição do DCAP, construindoformulários que depois são exportados para RDF ou para uma linguagem com a mesma estrutura que o DSP.Exemplos de implementação podem ser analisados em http://rdforms.com/editors/ - acedido em 21 Março2014.


https://bitbucket.org/metasolutions/rdforms/overview

http://rdforms.com/editors/


(máquinas) não são, num sistema como a WS, máquinas isoladas; na verdade todo o sistemasentirá o impacto das modificações. A implementação destas modificações num sistema quejá está em produção é algo que deverá ser antecipadamente bem planeado e discutido com acomunidade que implementa o DCAP, de forma a causar o mínimo de impacto nas aplicaçõesque o utilizam.

5.6 Desenvolver os Guias de Utilização

A actividade de Desenvolver os Guias de Utilização não é obrigatória já que o desenvolvimentodos Guias de Utilização não é obrigatório no Enquadramento de Singapura (c.f. Figura 5.12). Noentanto, o Me4DCAP recomenda o seu desenvolvimento uma vez que a documentação de qualquerprocesso de desenvolvimento é fundamental; a existência destes Guias ajuda os utilizadores finaisda aplicação do DCAP a aplicar correctamente as suas propriedades e é fundamental para osfuturos desenvolvedores entenderem o DCAP.

Figura 5.12: Diagrama de contexto da Etapa de Singapura: Desenvolver os Guias de Utilização

A actividade Desenvolver os Guias de Utilização deverá ser realizada (c.f. Figura 5.2)simultaneamente com: (i) a actividade Definir os Critérios de Adequação (c.f. Secção 5.5); (ii)a actividade composta Desenvolver o Pré-DSP (c.f. Secção 5.5); (iii) a actividade compostaDesenvolver a Validação em Laboratório (c.f. Secção 5.5); (iv) a Etapa de Singapura Desenvolveros Guias de Sintaxe (c.f Secção 5.7); (v) a Etapa de Singapura Codificar o Description Set Profile(c.f. Secção 5.5).

O guia DCMI refere: “O DSP define o quê de um perfil de aplicação; o Guia de Utilizaçãofornece o como e o porquê. Os Guias de Utilização oferecem instruções para os que irão criar osregistos de metadados. Idealmente, este Guia explica cada propriedade e antecipa as decisõesque têm de ser tomadas no curso da criação dos registos de metadados” Baker and Coyle (2009).Para informação detalhada ver Baker & Coyle (2009) e Nilsson et al. (2008).

Os Guias de Utilização deverão ser desenvolvidos pela equipe técnica assessorada peloEspecialista de Domínio de Aplicação; esta assessoria é importante porque é necessário saber adescrição dos atributos e das classes de objectos. De facto trata-se do tipo de informação que



só poderá ser fornecida por este perfil específico; a equipe alargada deverá validar o trabalhorealizado.

Esta Etapa de Singapura produz o deliverable não obrigatório Guias de Utilização.

5.7 Desenvolver os Guias de Sintaxe

A actividade Desenvolver os Guias de Sintaxe não é obrigatória já que o desenvolvimento dosGuias de Sintaxe não são obrigatórios no Enquadramento de Singapura (c.f. Figura 5.13). Noentanto, o Me4DCAP recomenda o seu desenvolvimento uma vez que a documentação de qualquerprocesso de desenvolvimento é fundamental; a existência destes Guias ajuda os utilizadores finaisda aplicação do DCAP a aplicar correctamente as suas restrições, e ainda assegura que futurosdesenvolvedores entendam como o DCAP está definido.

Figura 5.13: Diagrama de contexto da Etapa de Singapura: Desenvolver os Guias de Sintaxe

A actividade Desenvolver os Guias de Sintaxe deverá ser realizada (c.f. Figura 5.2) simul-taneamente com: (i) a actividade Definir os Critérios de Adequação” (c.f. Secção 5.5); (ii) aactividade composta Desenvolver o Pré-DSP (c.f. Secção 5.5), e; (iii) a actividade compostaDesenvolver a Validação em Laboratório (c.f. Secção 5.5); (iv) a Etapa de Singapura Desenvolveros Guias de Utilização (c.f Secção 5.6); (v) a Etapa de Singapura Codificar o Description SetProfile (c.f. Secção 5.5).

Esta actividade trata de “descrever as sintaxes específicas do perfil de aplicação” Baker andCoyle (2009); trata-se de explicar a forma como os SES e VES (a que o DCAP irá recorrerpara definir as restrições das propriedades das classes de objectos) devem ser aplicados. Parainformação mais detalhada consultar Baker & Coyle (2009) e Nilsson et al. (2008). Estedeliverable deverá ser desenvolvido pelo Desenvolvedor Semântico porque é um documento muitotécnico, com uma especificidade muito particular à WS.

Esta Etapa de Singapura produz o deliverable não obrigatório Guias de Sintaxe.



5.8 Sumário

Este capítulo apresenta o resultado principal deste doutoramento, o Me4DCAP. Trata-se de umprimeiro contributo para a concepção de um método para o desenvolvimento de um DCAP. OMe4DCAP tem como base o Enquadramento de Singapura (c.f. Nilsson el al. (2008)) e partede uma persectiva de engenharia de software, baseando-se nas primeiras fases de modelação dedados de processos de desenvolvimento de software, assim como nas práticas da comunidade demetatados no desenvolvimento de DCAP.

O Me4DCAP define quais as actividades necessárias realizar, quando devem ser estas activi-dades executadas, como estão interligadas e que artefactos elas produzem. O Me4DCAP defineainda a constituição da equipe ideal de trabalho para o desenvolvimento de um DCAP.


Capítulo 6

Situação experimental: um perfil deaplicação para a Economia Social eSolidária

LASTWork for what is lasting

Deng Ming-Dao

Este capítulo apresenta a situação experimental do nosso caso de investigação. Hevner (2007)define que uma tal situação pode ser utilizada para testar o trabalho de concepção de um artefactoque vai sendo desenvolvido em paralelo. No nosso caso, a concepção do Me4DCAP foi sendotestada no desenvolvimento de um DCAP-ESS. Este trabalho foi realizado com um grupo depessoas pertencente à rede de Economia Social e Solidária mundial. Este capítulo apresenta oresultado desses trabalhos, o DCAP-ESS V1.0.

6.1 Introdução

O interesse na área da ESS partiu de um contacto estabelecido com um membro dessa comunidademundial no sentido de contribuirmos para a resolução de um problema de interoperabilidadeentre os SIW da ESS. Esse trabalho enquadrou-se num grupo de organizações (a que damos aquio nome de consórcio) pertencentes a uma rede mundial de ESS, a RIPESS. A RIPESS é umarede mundial de redes de ESS, com presença em todos os continentes, englobando um total desessenta países. Este consórcio tem origem num trabalho que este grupo de organizações realizou,que consistiu num mapeamento das organizações (formais ou não formais) de ESS em cada umdos países representados no consórcio. Uma vez terminado o mapeamento, o consórcio prosseguiuos seus trabalhos no sentido de encontrar soluções de interoperabilidade para os seus SIW. Foino final desta primeira fase que se estabeleceu o contacto. O objectivo desta comunidade era ode criar uma rede mundial de ESS que lhes permitisse mostrar a sua dimensão real ao mundo.

A reunião de arranque para este novo objectivo aconteceu em Fevereiro de 2011, em Paris,

121

6. Situação experimental: um perfil de aplicação para a Economia Social e Solidária

na sede da organização Mouvement pour l’Économie Sociale1. Nessa reunião, que está reportadaem Apêndice na Secção B.1.1, os intervenientes trabalharam pela primeira vez na organização dainformação que desejavam ver partilhada entre todos, e posteriormente disponibilizada para afunção de descoberta da WS. Estivemos presentes nessa reunião de arranque, a partir de umconvite formulado pelo parceiro brasileiro. Nessa reunião criámos contactos pessoais para realizaras entrevistas exploratórias reportadas na Secção 6.2.2.4.2. Essas entrevistas serviram tambémpara estabelecer relações de confiança, uma vez que os entrevistados entenderam que tínhamosum objectivo comum, e que por isso faria sentido integrarem-nos também nos seus trabalhos.Desde a reunião de Paris que fomos monitorizando o trabalho do consórcio, integrando-nos nasreuniões de trabalho como observadores, no sentido de criar uma base de relacionamento quenos permitisse, mais tarde - pela base de confiança e de fidelização que fosse adquirida junto dogrupo - a realização de trabalho futuro (ver em Apêndice na Secção B.1 o relato do processo deacompanhamento).

O conjunto de organizações de que era composto o consórcio no início dos seus trabalhos era:Forum Brasileiro para a Economia Solidária (FBES)2 - Brasil; Zona Equosostenible (ZOES)3

- Itália; Mouvement pour la Économia Solidaire (MES)4 - França; Red de redes de EconomiaAlternativa y Solidária (REAS)5 - Espanha; Chantier pour l’Économie Sociale6 - Canadá; InstitutEuropéen de l’Economie Solidaire (IEES)7 - Luxemburgo. No entanto, desde Dezembro de2011, que novas organizações da RIPESS, interessadas na temática, começaram a participarnas reuniões. O grupo organizou-se recorrendo a uma mailing-list8 e as reuniões foram sendorealizadas com quem desejava estar presente, com os contributos que cada um dava. Apesar dasua volatibilidade, estiveram sempre presentes os representantes FBES, ZOES e MES.

Em Outubo de 2012 o consórcio entendeu que era necessário realizar uma reorganizaçãointerna (nacional) e externa (internacional) de forma a que as várias organizações que copõem oconsórcio pudessem ter a mesma (ou quase a mesma) interpretação dos seus dados; desta formaseria possível implementar a interoperabilidade de dados entre os seus SIW. Era claro paraeles que seria necessário encontrar um enquadramento comum de entendimento. Nessa data,o mapeamento das organizações a nível de todas as redes que compunham as organizações doconsórcio estava terminada, assim como o desenvolvimento de três listas controladas de termos(das quatro listas planeadas para desenvolver). O consórcio estava ciente de que a utilização deesquemas de metadados é uma forma de resolver as suas necessidades de interoperabilidade, umavez que é possível usar vocabulários, classes e propriedades para descrever recursos dentro de umacomunidade Rühle et al. (2011). Contudo, foi-lhes explicado que a conformidade com os esquemasde metadados não era suficiente para que os seus SIW atingissem uma interoperabilidade semântica

1c.f. http://www.le-mes.org - acedido em Junho 2011.2http://www.fbes.org.br/ - acedido a 21 Janeiro 2014.3Zona eco-sustentável - http://www.zoes.it - acedido a 21 Janeiro 2014.4Movimento para a Economia Solidária: http://www.le-mes.org - acedido a 21 Janeiro 2014.5Rede de redes de economia alternativa e solidária - http://economiasolidaria.org/ - acedido a 21 Janeiro

2014.6Oficina para a economia social - http://www.chantier.qc.ca/ - acedido a 21 Janeiro 2014.7Instituto Europeu de Economia Solidária - http://www.inees.org/ - acedido a 21 Janeiro 2014.8Interoperability for ESS Information Systems <[email protected]>


http://www.le-mes.org

http://www.fbes.org.br/

http://www.zoes.it

http://www.le-mes.org

http://economiasolidaria.org/

http://www.chantier.qc.ca/

http://www.inees.org/


internacional. Para atingir o nível 4 de interoperabilidade da Dublin Core (ver Figura 2.3) haveriaa necessidade de desenvolver um DCAP.

Por essa razão a RIPESS decidiu desenvolver um DCAP que baptizamos com o nomeDCAP-ESS. Para realizar esse trabalho foi criada uma nova equipe, liderada por nós. Utilizamosesta situação para integrar o trabalho de desenvolvimento do DCAP-ESS no processo de definiçãode um método para o desenvolvimento de DCAP, objectivo da nossa investigação. Esta situaçãofoi a “situação experimental” definida por Hevner (2007), como já referido no Capítulo 3.2. Asreuniões de trabalho para o desenvolvimento do DCAP-ESS iniciaram-se em 23 de Outubro de2012 e terminaram - nesta primeira fase enquadradas no trabalho de doutoramento - a 9 de Abrilde 20139.

As secções seguintes apresentam o trabalho desenvolvido para a construção do DCAP-ESS. Écerto que os trabalhos realizados ao longo do processo não foram desenvolvidos exactamente comoindicado na versão final do Me4DCAP, no entanto eles foram realizados nesse enquadramentoe serviram para definir o Me4DCAP como referido no capítulo 4. Por esta razão o trabalhodesenvolvido é apresentado nas secções seguintes sob o ponto orientador do Me4DCAP.

Os documentos produzidos no âmbito do consórcio são apresentados em Inglês porque essefoi o idioma utilizado.

6.2 Desenvolver os Requisitos Funcionais

A Secção 5.3 define que esta actividade composta desenvolve as actividades apresentadas naFigura 6.1.

No final deverá produzir os seguintes artefactos:• Documento Visão (Ver Secção 6.2.1);• Plano de Trabalho;• Environmental Scan - Estado da Arte do contexto de aplicação (Ver Secção 6.2.2);• Requisitos de alto-nível (Ver Secção 6.2.3);• Modelo de Casos de Uso (Ver Secção 6.2.4).A actividade composta termina com o desenvolvimento do deliverable Requisitos Funcionais

(Ver Secção 6.2.5). Não apresentamos o artefacto ”Plano de Trabalho“ pois não faz sentido nestecontexto.

A actividade composta ”Desenvolver o Modelo de Casos-de-Uso“ (c.f. Figura 6.2) produz osseguintes artefactos: (i) Diagrama UML de Casos-de-Uso; (ii) Casos-de-Uso Detalhados.

6.2.1 Documento Visão

ESSglobal is an initiative of some RIPESS members with the following objectives:• Increase the international visibility of the activities and products of solidarity economy;• Pool the methods and tools of mapping projects that already exist and that are beingdeveloped;

9Ver Apêndice B.1 para a descrição das reuniões.



Figura 6.1: Diagrama de contexto da Etapa de Singapura: Desenvolver os Requisitos Funcionais

• Develop transversal projects of human and economic cooperation among the participantsof the working group;

• Cooperate with other initiatives (existing or being created) that specialise in informationsystems, in the georeferencing of actors in the solidarity economy, and in networking.

In its first phase, ESSglobal participants agreed on four controlled vocabularies (also calledstandards) with a common set of IDs:

• Products and Services;• Qualifiers for products and services;• Economic sectors;• Macro Themes.These standards, the guidelines for Social and Solidarity Economy (SSE) networks and

information systems to join ESSglobal, and a simple way of using the standards for sharing dataand producing a global map of SSE initiatives are available in a document10.

As a second phase of the ESSglobal initiative, a DCAP will be developped to enhanceinteroperability among SSE Information Systems. By developing a Dublin Core Application

10Disponível no Wiki: http://purl.org/essglobal/wiki




Figura 6.2: Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Modelo deCasos-de-Uso

Profile for the Social and Solidarity Economy (DCAP-SSE), ESSglobal aims to provide the meansfor SSE Information Systems to belong to the Semantic Web paradigm.

DCAP-SSE will treat the following information dimensions:• Commerce;• Public visibility;• Research and statistics;• Network building;• Public policies;• Education.The dimensions ”Education“ and ”Public policies“ are not taken into account in this first

version of DCAP-ESS.

6.2.2 Estado da arte do contexto de aplicação


Para desenvolver o estudo do estado da arte do contexto de aplicação foram inicialmente realizadaspesquisas bibliográficas. Nestas pesquisas foram encontrados artigos científicos que serviram desuporte para desenvolver o enquadramento teórico apresentado na secção 6.2.2.3. No entanto,não foi encontrado qualquer material que referisse trabalhos científicos relativos à reflexão sobremetadados, PA ou interoperabilidade na área específica da ESS. Por essa razão foi necessário:

• Identificar as organizações congregadoras das redes de ESS, e realizar um estudo exploratóriodessas organizações e dos seus objectivos de interoperabilidade;

• Identificar os SIW de apoio ao desenvolvimento das redes das organizações identificadas, erealizar um estudo exploratório desses SIW.

Com o sentido de desenvolver estes trabalhos, realizamos: (i) entrevistas aos representantesdas organizações que fazem parte do consórcio RIPESS; (ii) um estudo dos SIW da ESS.

6.2.2.2 Metodologia de trabalho

Esta secção apresenta a metodologia de trabalho utilizada:• nas pesquisas bibliográficas - c.f. secção 6.2.2.2.1;



• nas entrevistas por Skype aos representantes das organizações que fazem parte do consórcioRIPESS - c.f. secção 6.2.2.2.2;

• na análise dos SIW da ESS - c.f secção 6.2.2.2.3.

6.2.2.2.1 Estratégias de pesquisaForam efectuadas pesquisas bibliográficas com pesquisas gerais e depois refinadas nas bases de

dados online. As bases de dados utilizadas foram o Google Scholar11, o ISI Web of Knowledge12,o SCI ETD Networked Digital Library of Thesis and Dissertations13, o Scopus14 e o Oaister15.

As palavras chave introduzidas na pesquisa foram: Economia Social e Solidária, Interoperabi-lidade e Economia Social e Solidária, Economia Social e Solidária e e-government; EconomiaSocial e Solidária e metadados; Economia Social e Solidária e esquemas de metadados; EconomiaSocial e Solidária e perfis de aplicação. As pesquisas foram realizadas em Inglês, em Português,em Espanhol e em Francês. O Inglês por ser o idioma mais usado na comunidade científica; osrestantes por serem idiomas de países onde a Economia Social e Solidária está mais desenvolvida(América Latina, em especial no Brasil) Singer and Schiochet (2006).

As pesquisas foram realizadas no campo ”título do artigo“ e no campo ’corpo do artigo”, coma excepção de quando se pesquisou por um autor específico, nesse caso, a pesquisa foi realizadano campo ”autor“. Incialmente os artigos foram seleccionados seguindo o critério de ”relevânciado título“, “número de citações” e de ”revista científica” (com um factor de impacto JCR/SJRmais elevado). Numa fase posterior, foram pesquisados artigos a partir do nome dos autoresrelevantes identificados até à data.



6.2.2.2.2 EntrevistasOs trabalhos iniciaram-se numa reunião em Paris, organizada pela RIPESS a 26 e 27 de

Março de 2011. Nesta reunião estiveram presentes os representantes de Organizações RIPESSque estudam entre si a possibilidade de implementar interoperabilidade entre os seus SIW, ao qualchamamos de Consórcio. Nessa reunião estabeleceram-se os primeiros contactos para programaruma série des entrevistas exploratórias a realizar via skype (utilizando também vídeo).

Os entrevistados receberam um guião uma semana antes da data acordada para a entrevista(Guião disponível em Apêndice B.1.3). Foi-lhes pedida autorização para a gravação audio daentrevista: pretendiamos fazer a sua transcrição. Todos os entrevistados concordaram com a

11http://scholar.google.com - acedido em Junho de 201112http://www.isiWebofknowledge.com - acedido em Junho 201113http://www.ndltd.org/serviceproviders/scirus-etd-search - acedido em Junho 201114http://www.scopus.com - acedido em Junho 201115http://oaister.worldcat.org - acedido em Junho 2011








gravação e com a publicação do audio e transcrição num repositório aberto16. Só um potencialentrevistado17 não se mostrou disponível para realizar a entrevista por falta de tempo, adiandopara uma outra oportunidade. Foi, no entanto, o primeiro elemento a mostrar-se disponível paraajudar neste estudo e o responsável pelo convite para a participação na reunião acima referida.

As entrevistas foram informais e semi-estruturadas uma vez que o perfil de cada um dosentrevistados era diferente, e o seu conhecimento técnico relativamente aos sistemas de informaçãoWeb e contexto ESS, variado. Alguns entrevistados responderam por email, antes da entrevista, àsperguntas mais simples e objectivas pelo que quando a entrevista foi realizada essas perguntas nãoforam colocadas. Na Tabela 6.1 apresentamos a lista das entrevistas. Na Tabela 6.2 apresentamosos respectivos handles contendo o dataset18 com o audio e as transcrições das entrevistas.

Tabela 6.1: Lista das entrevistas exploratórias Réseaux Intercontinental de Promotion del´Economie Sociale Solidaire.

Entrevistado(a) Organização PaísA Chantier de l’Economie Sociale Canadá (Québec)B Fondazione Culturale Banca Etica ItáliaC I. Européen de l’Économie Solidaire LuxemburgoD Mouvement pour l’Économie Soli-

daireFrança

E Red de redes de Economia Alterna-tiva y Solidaria

Espanha

F Vivir Bien Austria

Os excertos de transcrições referidos são apresentados no idioma da entrevista, sem tradução.

6.2.2.2.3 Análise dos Sistemas de Informação WebNão tendo sido encontrado qualquer material na revisão de literatura que referisse trabalhos

científicos ou fornecesse informação relativa à reflexão sobre os SIW e interoperabilidade entre osSIW na área específica da ESS, foi necessário desenvolver outros esforços para obtermos maisinformação.

O nosso ponto de partida foi a RIPESS19, que é uma plataforma a nível mundial para apromoção da ESS. Esta rede é composta por redes nacionais ou sectoriais, e é o chapéu da ESSno mundo; organiza-se por região, sendo composta por: RIPESS América do Norte20, RIPESSAmérica Latina e Caraíbas21, RIPESS Europa22, RIPESS África e RIPESS Ásia23.

Os SIW para o estudo foram identificados a partir do sítios Web da RIPESS e ainda a partirdas entrevistas realizadas (c.f. secção 6.2.2.2.2). O critério de escolha foi:

16As transcrições foram revistas pelos entrevistados, sobretudo porque foram realizadas no idioma maternodestes (excepção entrevistado Austríaco) o que poderia trazer erros ou gralhas de transcrição

17FBES18Disponível em acesso aberto.19RIPESS Intercontinental: http://www.ripess.org/ - acedida a 1 Abril 2014.20http://ripessna.wordpress.com/ - acedida a 1 Abril 201421http://www.ripesslac.net/ - acedida em Junho 2011. A 1 de Abril, sítio desaparecido.22http://www.ripess.net - acedida Junho 2011. A 1 de Abril 2014, sítio desaparecido.23http://www.aa4se.com/cms2/ - acedida em Junho 2011. A 1 de Abril 2014 sítio desaparecido.


http://www.ripess.org/

http://ripessna.wordpress.com/

http://www.ripesslac.net/

http://www.ripess.net

http://www.aa4se.com/cms2/


Tabela 6.2: Links das entrevistas exploratórias Réseaux Intercontinental de Promotion del´Economie Sociale Solidaire.

Entrevistado(a) LinkA http://hdl.handle.net/1822/18422B http://hdl.handle.net/1822/18420C http://hdl.handle.net/1822/18426D http://hdl.handle.net/1822/18424E http://hdl.handle.net/1822/18425F http://hdl.handle.net/1822/18427

1. Encontrar pelo menos um sistema em cada continente. Mesmo sendo esse único sistemamuito fraco (caso Asiático), a análise preliminar foi realizada;

2. havendo mais do que um sistema, seleccionar os contendo pelo menos algumas das funcio-nalidades definidas abaixo.

Na primeira parte da análise, foram analisados todos os sistemas dentro do critério enumerado.Numa segunda parte da análise desses sistemas, foram seleccionados para análise e para base doestudo do estado da arte, os sistemas das organizações cujos representantes estiveram presentesna reunião referida. Estas organizações já possuiam SIW um mapeamento das organizações deESS no seu país. Estes foram analisados do ponto de vista do utilizador, tendo como base osseguintes parâmetros:

• Mapping: se está a participar no programa de mapeamento das organizações ESS da suarede;

• Temáticas;• Events;• News;• Blog;• Rede Social: é um espaço privado onde funcionalidades de rede social existem (como a redeprivada facebook, por exemplo);

• Catálogo de produtos/serviços;• Venda online:

– Sim ou Não;– Observações.

• RSS;• TAG:

– Sim ou Não;– Níveis.

• Metadados:– Sim ou Não;– Quais.

Este estudo foi realizado entre Janeiro e Março de 2011.









6.2.2.3 Economia Social e Solidária

A “outra economia“, ou a Economia Social, Economia Solidária, Terceiro Sector ou Sector nãolucrativo, é uma terceira via de actuação das sociedades, distinta da economia de mercado eda economia pública estatal. É uma economia que se “apresenta como alternativa material ehumana superior à economia capitalista”(Cattani et al., 2009, p. 162). Existem várias visõespara caracterizar esta “outra economia”, mas é certo que a maior parte das caracterizações têmem comum a forma como as instituições se organizam, com o fim de beneficiar o grupo de pessoasda organização e a sociedade/comunidade onde a organização se insere. Estes fins têm a vercom formas de ver o papel dos cidadãos no espaço social, formas estas que se opõem a práticasconsideradas predatórias do mundo capitalista, tanto a nível económico, social e ambiental.

Tendo vindo a estudar mais pormenorizadamente as organizações no mundo inteiro que aspraticam, os cientistas sociais em geral e os sociólogos em particular verificam pequenas diferençasconceptuais entre estas formas de associação, sendo estas essencialmente políticas e culturais.Para o trabalho que pretendemos desenvolver, interessa-nos a focagem sobre os conceitos deEconomia Social e Economia Solidária uma vez que é segundo estes conceitos que se auto-definemas organizações envolvidas no estudo.

Segundo Cattani (2009), a Economia Solidária é um conceito amplamente utilizado em várioscontinentes, com acepções variadas que giram ao redor da ideia de solidariedade. Este conceitodisseminou-se no início dos anos 90 do século XX, com o reaparecimento de muitas iniciativas decidadãos que se associaram segundo princípios de cooperação, autonomia e gestão democrática.

Desde o século XIX que as cooperativas e mutualidades existem nas sociedades ocidentais,tendo como princípio satisfazer as necessidades dos seus membros a partir do desenvolvimento deoutros valores que não o lucro capitalista. As cooperativas têm como princípios outras formas deorganização do trabalho, de produção de bens e de circulação de riqueza que as do capitalismo,preferindo a cooperação, a auto-gestão por parte dos membros e a autonomia face ao capitalprivado. Nos países periféricos, esta associação de trabalhadores surgiu como alternativa paratrabalhadores quer rurais quer urbanos, utilizando práticas tradicionais e autóctones de produçãode bens e serviços, fazendo prevalecer o sentimento comunitário. Com o desenvolvimento intensoda economia de mercado, no século XX, o cooperativismo integrou-se muitas vezes na economiade mercado capitalista. O associativismo entrou também em declínio com o desenvolvimento dosEstados Sociais, integrando-se na sociedade para preencher funções sociais, que complementavamas do Estado. Estas funções estão relacionadas com apoio a camadas desfavorecidas da populaçãocomo sejam o apoio a idosos e a indivíduos com necessidades especiais.

A partir dos anos 80 do século XX, as crises económicas e sociais com forte impacto no trabalhoe no desemprego, sobretudo criado pela deslocalização de empresas para países mais pobresonde a mão de obra é mais barata e os trabalhadores menos protegidos socialmente, trouxeramo resurgimento do associativismo. Segundo Cattani (2009), o desenvolvimento tecnológicoembora tenha trazido melhores condições de trabalho, trouxe também aspirações a um maiorenvolvimento na gestão dos processos e uma maior intervenção no mundo do trabalho, tornandoos trabalhadores indivíduos com maior consciência do seu poder. A estas modificações sociais



foram-se agregando outras questões prementes da sociedade, tais como a preocupação coma ecologia, com o desenvolvimento sustentável, com os direitos e deveres do cidadão, com aigualdade de género e com o respeito pelas minorias, individualidades e culturas.

A Economia Solidária caracteriza-se então pela solidariedade e pela igualdade, pela possecolectiva do trabalho e pela não alienação deste - em contraponto com a economia de mercado,onde o poder está centralizado em quem tem o capital económico. A Economia Solidária baseia-sena ideia de que quem não tem capital não é necessariamente menos capaz e tem portanto direitoa chamar a si tarefas mais complexas e menos alienantes. Este é um dos princípios da EconomiaSolidária: a alienação do trabalho é uma forma negativa de colocar o indivíduo no mundodo trabalho. Tornar o indivíduo responsável pelo seu trabalho faz dele um ser mais inteiroe responsável, por si, pelo colectivo, pela rede onde se integra, e pelo mundo na globalidade.A Economia Solidária é hoje composta por agrupamentos de pessoas mais ou menos formais,que integra as associações em geral, cooperativas e sociedades mutualistas, bem como os novosmovimentos sociais, a economia popular e familiar, as empresas auto-geridas (sobretudo nospaíses da periferia mundial).

O outro conceito que focamos é o de Economia Social. ”A Economia Social (...) é um conceitoque emerge (...) como uma maneira de fazer economia política.” (Lechat, 2007, p. 162). Apreponderância é posta na “busca da democracia económica associada à utilidade social” (Cattaniet al., 2009, p. 156). A Economia Social nasce para resolver problemas sociais que o Estadonão consegue resolver. Esta forma de fazer economia tem a sua pré-história nas mais remotasassociações humanas no Egipto, na Antiguidade Greco-latina, na Europa da Idade Média, naChina Imperial ou na América Pré-Colombiana. Estes eram sistemas de ajuda mútua, tantoprofissionais como religiosos ou artísticos. No século XXI sociólogos caracterizam EconomiaSocial de duas formas: uma do ponto de vista da identificação das principais formas jurídicas ouinstitucionais encontradas (cooperativas, sociedades mutualistas, associações e fundações); outraatravés da identificação dos traços comuns das empresas e das organizações (lucro secundário;autonomia de gestão, controlo democrático; primazia das pessoas e do objecto social sobre ocapital na distribuição dos excedentes) Lechat (2007). É neste mesmo sentido que estas duasabordagens na Economia Social coexistem.

Havendo efectivamente uma distinção entre os conceitos de Economia Solidária e de EconomiaSocial, ela acontece enquadrada em contextos espaço-temporais distintos, com característicassociais, económicas, culturais ou até mesmo políticas diferenciadas.

Entendemos que a distinção entre Economia Solidária e Economia Social reside na tomadade consciência do indivíduo do seu papel activo na sociedade: a Economia Solidária é feita deindivíduos não alienados, assenta num projecto de sociedade alternativo com uma tomada deconsciência do seu papel na sociedade e do que desejam fazer atraves desta “terceira via“Cattaniet al. (2009). A Economia Social tem uma esfera mais restricta de expectativas, não se afirmandocomo um projecto político. Está muito associada a formas jurídicas de instituições complementaresao papel social do Estado.

Neste estudo a distinção destas formas de “outra economia” não é essencial e por essa razãoutilizaremos o acrónimo ESS para a identificar, na linha de orientação de Laville (2009).



6.2.2.3.1 A Economia Social e Solidária e a Economia de MercadoA ESS é formada por um conjunto de organizações com diferentes constelações interagindo

entre si e envolvendo, em conjunto, um grande número de cidadãos em todo o mundo que procura,mais ou menos conscientemente, construir um modelo diferente para a sociedade.

A ESS vive “dentro” da economia de mercado, e é, ideologica e politicamente, sua subordinada.Não é contudo escrava dessa Economia de Mercado, é antes uma resistente: tem esperança que oactual modelo de sociedade mude no futuro. A ESS incorpora então uma alternativa; ela temoito vectores que dão força a esta alternativa. A ESS:

• promove uma reforma da sociedade presente, propondo assim um modelo diferente paraessa sociedade;

• pratica formas de governança democráticas promovendo assim a democratização da socie-dade;

• é feita de organizações solidárias e não lucrativas pelo que transfere o valor da solidariedadena sua forma de estar no mundo;

• põe no centro das suas preocupações o trabalhador, dando-lhe oportunidade para aprendere evoluir através do seu trabalho;

• promove a educação e formação do indivíduo ao longo da vida;• é um instrumento forte de compreensão do mundo, uma vez que olha para os cidadãoscomo sujeitos integrais socio-culturais e não apenas como consumidores;

• tem uma utilidade social, não trabalha para a produção do supérfulo, tendo padrões deconsumo mais frugais e justos;

• promove formas de desenvolvimento local ao dedicar-se a serviços de proximidade, estandoassim a contrariar as formas de desenvolvimento baseadas na globalização;

• coloca o trabalho como prioridade sobre o capital.

6.2.2.3.2 Importância da Economia Social e Solidária a nível globalA ESS encontra-se hoje em todos os continentes, levando à organização de redes locais,

nacionais, internacionais e até mesmo inter-continentais Singer (2008) Lechat (2007). Ela é parteda sociedade civil, e integra-se numa sociedade liberal e capitalista, interagindo com esta. É umsector com alguma importância económica: estudos recentes indicam que a ESS é uma forçaeconomica significativa. Por exemplo em Portugal, em 2010, o Valor Acrescentado Bruto (VAB)da Economia Social representou 2,8% do VAB nacional total; a Economia Social foi 5,5% doemprego remunerado, e é constituída por 55 383 instituições INE (2013). A ESS tem ganhoimportância no mundo inteiro, e em particular na Europa, não somente pelo facto de haver umaumento da procura de serviço sociais mas também pelo facto de existirem transformações nopapel do Estado na estrutura da sociedade. Este factor deve-se à evolução ideológica nos Estados:quanto mais neoliberal o Estado é, menor é a sua responsabildade nos campos sociais Evers andLaville (2004). A retracção do Estado Social tem variado na relação directa do resurgimento daESS.

Sendo a ESS uma parte importante da economia, alguns países ou governos dão-lhe, agoramais do que nunca, relevo no combate à pobreza e desenvolvimento humano, e por essa razão



integraram nos seus programas, políticas de apoio à ESS. Em alguns governos verificam-se“ações mais aprofundadas do ponto de vista da ação em si e do consenso interno com relação àEconomia Solidária, ao tempo em que, em outros, verificam-se ações mais pontuais e residuais”Schiochet (2009). Na União Europeia, o Parlamento Europeu lançou uma resolução relativamenteà Economia Social, focada na importância da Economia Social na sociedade e na necessidade decriar políticas de apoio e de enquadramento Parliment (2009).

Os melhores exemplos a relatar são o Brasil, o Luxemburgo e França, mostrando um compro-metimento mais profundo em relação à ESS. O Brasil, com o governo Lula (2003-2010), criouuma Secretaria de Estado específica para a ESS (Secretaria de Estado da Economia Solidária).É neste momento o país onde a ESS tem oficialmente mais significado. Estudos recentes, como ode Singer and Shiochet (2006) revelam a existência de 15 000 empreendimentos de EconomiaSolidária em 2005, tendo esse valor evoluído para 22 000 em 2008 Singer (2008). No Luxemburgofoi nomeado um ministro delegado para a Economia Social24, e em França, no Governo deFrançois Hollande (2012-2014) foi nomeado um secretário de estado para a ESS25. Estes factosabrem portas para um movimento crescente de acções, estudos e organização da ESS nestespaíses.

Em 2011 10% da população mundial está integrada em cooperativas vinculadas à AliançaCooperativa Internacional26, o que corresponde a um valor entre 600 e 700 milhões de pessoasSinger (2008).

6.2.2.3.3 A Economia Social e Solidária em redeA sociedade em rede Castells et al. (2000) como arquétipo das sociedades contemporâneas

ocidentais é um conjunto “de unidades sociais e de relações, directas ou indirectas, entre essasunidades sociais, através de cadeias de dimensão variável” Cattani et al. (2009). Neste tipo desociedade, as organizações percebem cada vez mais a necessidade de se articularem com outrosgrupos com a mesma identidade social e política, de forma a ganhar visibilidade e produzirimpacto na esfera pública e obter conquistas para a cidadania Scherer-Warren (2006). As redesaproximam actores sociais diferentes, possibilitando um diálogo de diversidade de interessese de valores Scherer-Warren (2006). Este diálogo traz naturalmente espaços de partilha deconhecimento e de experiências, “fermentadores” da auto-estima e do auto-conhecimento. Porsua vez, o acesso às redes permite aumentar o capital social das organizações, uma vez que ocapital social se estrutura nos vínculos estabelecidos a partir das relações entre pessoas. O capitalsocial, disponível nas comunidades, é um elemento potencializador de desenvolvimento (ao ladodo capital humano e físico) Fontes (2008).

A ESS é, como já foi dito anteriormente, constituída por agrupamentos mais ou menosformais de pessoas, associações, cooperativas ou sociedades mutualistas. Esta diversidade deorganizações pode trazer alguma complexidade à cooperação entre organizações, no entanto ela é

24“ministre délegué pour l’économie sociale”.25“ministre délegué pour l’économie sociale et solidaire Benoît Hamon”. A 2 de Abril de 2014 com a remodelação

do Governo por demissão do primeiro-ministro após eleiçoes municipais, ainda não há informações sobre se esteministro delegado continua a existir.

26http://www.ica.coop/al-ica/ - acedido em Junho 2011.


http://www.ica.coop/al-ica/


considerada vital para o seu fortalecimento. É também uma oportunidade para as organizaçõesporque permite a implementação de redes de intercâmbio. O que se presencia hoje no contextoda ESS é um conjunto de movimentos sociais, organizações em rede ou cadeias de produção quedão à ESS uma dimensão considerável. A integração nas redes é uma integração de elementosiguais cujo objectivo é a possibilidade de ganhos na escala de produção e na homogeneização deprodução e comercialização FBES and de l’Economie Social (2008). Além disso, não se tratasomente de integração económica, mas também do estabelecimento de laços sociais baseados nosprincípios basilares da relação entre empreendimentos de ESS, a dádiva, a partilha, o preço justo.A existência de meras relações comerciais não implica necessariamente a integração numa rede.Aqui a rede é entendida pelos laços que se estabelecem entre os diferentes empreendimentos que acompõem e que trabalham para um objectivo de bem comum. Acrescendo ao capital económicoo designado capital social Bourdieu (1980).

Esta estrutura de rede existente a nível local, nacional e internacional, e ainda sectorial,permite às organizações o acesso a estratégias de acção, partilha de recursos, possibilitandodeslocamentos na estrutura social Cattani et al. (2009). Esta possibilidade de deslocamentona estrutura social é particularmente importante na ESS, apoiada numa “economia de sujeitosdesiguais”, de indivíduos frequentemente muito pobres ou de camadas desfavorecidas, sem acessoa capital económico e por isso com difícil acesso ao mercado e ao conhecimento. Em rede,adquire-se mais poder, mais oportunidades e visibilidade social, desenvolvem-se nomeadamenterelações de troca de bens ou serviços, de trocas solidárias, relações sociais (espaços de partilha efortalecimento pessoal e organizacional) e agendas cooperativas27. Os tipos de relações em redeexistentes na ESS são vários e dependem muito do país onde se inserem. Existem três níveis deredes que estão organizadas a nível local, nacional e internacional. Existe ainda uma dimensãotransversal a esta classificação, a sectorial. A redes sectoriais definem-se numa dimensão deafinidade: os produtores de algodão, os produtores de milho, os cuidadores de idosos, comoexemplos Scherer-Warren (2006).

A Figura 6.3 refere-se a organizações de ESS que se articulam localmente, organizando-se emplataformas locais de ESS. Há países onde esta rede complexa de organização local, regional enacional não existe e há outros onde a organização e mobilização são muito grandes. No Brasil, porexemplo, existem os Foruns Estaduais de Economia Solidária28 constituídos essencialmente porempreendimentos de ESS (cooperativas, associações, pessoas ou grupos de pessoas organizadasinformalmente) mas também gestores públicos e outras organizações sem fins lucrativos. Estasorganizações transaccionam entre si bens e serviços, mas também efectuam trocas solidárias etêm encontros de reflexão e debate. A troca de serviços entre parceiros de ESS é algo muitocomum. Ajudam-se os “desiguais”. É frequente acontecer a transacção de bens entre organizaçõesde Economia Solidária formando uma cadeia de solidariedade: as cadeias produtivas. São umexemplo do que pode ser uma rede local, regional e até nacional. As cadeias produtivas são formasde integração de unidades de produção que se complementam. Estas unidades são responsáveis

27As agendas cooperativas são reuniões específicamente usadas para marcação de compromissos colectivos econciliação de disponibilidades para reuniões.

28http://www.fbes.org.br/ - acedido em Junho 2011.


http://www.fbes.org.br/


Figura 6.3: Redes locais e cadeias produtivas de Economia Social e Solidária.

por um processo de transformação que vai desde a matéria prima ao produto final.

Um excelente exemplo de uma cadeia produtiva é a Justa Trama29 Singer (2008). Esta começa(ver figura 6.4) no Ceará (Brasil) com os produtores de algodão orgânico, passa por S. Paulo ondeuma empresa recuperada (administração tomada em regime de auto-gestão pela comissão detrabalhadores depois de declarada falência pela administração capitalista) fia o algodão, depoissegue para uma outra empresa recuperada para produzir os tecidos, e termina nas cooperativasde confecção e de costureiras que transformam os tecidos em roupas a serem vendidas segundo amarca “Justa Trama”. Uma cadeia produtiva pode realizar-se tanto ao nível local, regional ounacional. Na Figura 6.5 apresentam-se as relações existentes a um nível nacional e internacional,inspirada na actual orgnização do RIPESS. São espaços de encontro nacionais ou internacionais,onde as plataformas locais (organizações locais que elegem os seus representantes) se fazemrepresentar em eventos ou plataformas regionais, nacionais e/ou internacionais (dependendonaturalmente da dimensão do país). Existem também redes sectoriais. A organização destesespaços de encontro nacionais é mimetizada nos SIW. Estes SIW suportam a organização destasredes dando-lhe uma visibilidade muito grande, potenciando as relações e transacções já existentesno terreno. Os SIW fortalecem os laços e as estruturas já existentes no terreno, e permitema criação de novas relações, por vezes impensáveis sem a existência destes sistemas, devido àsdistâncias geográficas. As organizações “chapéu” de cada país, que reunem as organizações locais,regionais e nacionais do seu país, juntam-se na RIPESS, um espaço mundial de promoção daESS, que é o nosso contexto de aplicação de desenvolvimento do DCAP-ESS.

29http://www.justatrama.com.br - acedido em Junho 2011.


http://www.justatrama.com.br


Figura 6.4: Exemplo de cadeia produtiva de Economia Social e Solidária - caso Justa Trama.

6.2.2.4 Estudo sobre os Sistemas de Informação Web da Economia Social e Solidá-ria

6.2.2.4.1 IntroduçãoO percurso efectuado pela RIPESS até ao momento em que iniciamos os nossos trabalhos

com esta organização, tinha sido a realização, por parte de cada membro-país30, do mapeamentoda ESS nos seus países. No passado também estas organizações foram trocando informalmenteinformações sobre os seus SIW, e sobre o seu desejo de troca/partilha de informações entre si.Os objectivos eram:

• Visibilidade: Esta visibilidade é importante a vários níveis já que se mostra o potencial darede mundial de ESS, tanto a nível do consumidor final; para o consumo mas também paraa sua conscientização (consumo responsável), como a nível dos governos que entendem deuma forma clara a dimensão do sector;

• Maior dimensão das redes: As redes nacionais poderão saltar as fronteiras nacionais,permitindo-se o contacto com Organizações congéneres a nível mundial, que de outra forma,por si só, jamais teriam a capacidade de o fazer.

Iniciamos trabalhos para compreender com mais detalhe as organizações “chapéu” das redes deESS no mundo. O ponto de partida foi a reunião de arranque “Cartographie Internationale”31

organizada pela RIPESS em Paris a 26 de Março de 2011. Na reunião estiveram presentes oslíderes das organizações de ESS que possuem SIW32 e que participam no mapeamento da ESS nos

30E não se trata de todos os países que pertencem à RIPESS mas somente aqueles que estavam comprometidoscom o mapeamento das organizações de ESS do seu país.

31Cartografia Internacional.32Quando nos referimos a SIW - estamos a referir-nos a sistemas de informação baseados na tecnologia Web,



Figura 6.5: Redes regionais, nacionais, internacionais e sectoriais de Economia Social e Solidária.

seus países. Esta reunião foi a primeira onde oficialmente se discutiu o tema da interoperabilidadeentre os SIW de ESS. O resumo da reunião pode ser consultado no Apêndice B.1.1. Nessareunião foram estabelecidos contactos para a realização das entrevistas já referidas (trabalhorelatado na secção 6.2.2.4.2.

É então neste contexto que desenvolvemos os estudos que relatamos de seguida.

6.2.2.4.2 Resultados - Entrevistas consórcioRealizamos um conjunto de entrevistas por Skype aos representantes das organizações que

fazem parte do consórcio RIPESS. Os objectivos específicos destas entrevistas exploratóriasforam:

• Identificar os elementos líder do movimento de cartografia internacional para encontrarinterlocutores capazes de diálogo a nível técnico;

• Identificar os elementos líder do movimento de ESS com visão estratégica mundial;• Entender quais os SIW, seu conteúdo, sua importância no panorama da comunidade deESS do país;

• Identificar as necessidades de interoperabilidade dos sistemas de informação Web dacomunidade ESS, e entender o contexto destas necessidades.

Foram entrevistados os indivíduos já listados nas Tabelas 6.1 e 6.2.As entrevistas revelaram um conjunto de informações muito importante para uma compreensão

real do tipo de comunidade que é a ESS, assim como para o entendimento das necessidades deinteroperabilidade.

que podem ser integrados em sistemas de informação comuns Yang and Tang (2003).



A primeira conclusão a que chegámos é a de que as organizações de ESS que estão presentesno consórcio estão desejando muito fortemente realizar a partilha de informação entre elas:

”My idea is that both in Italy and internationally we should start sharing theinformation we have inside (. . . ) the idea of the project we are doing with RIPESS isthat we will be able to share information with common filters, so that it is comparableinformation, not just a copy of that information: you can compare and work on itand to find information to aggregate it (. . . ).“ Entrevistado B

A segunda conclusão é que existem grandes diferenças culturais - a nível de cada país mastambém a nível interno a cada país: isto traz implicações na forma como se auto-definem, e nabusca de entendimentos na definição de classificação de recursos e de vocabulários comuns:

”(...) in Brazil is quite interesting now they have this State Secretariat for the Solida-rity Economy and it is a different development but in Austria we have a huge traditionof really having the state involved very much (...) and also in Germany, people whofind themselves under these term of Solidarity Economy are very grass-roots and veryinformal organized, not like in France.” Entrevistado B

”Some for instance insist a lot in having more detail, like the Brazilians in what kindof services and products, others are more interested in more descriptive kind of thingsso the kind of information you find there is more blog kind of information. So itdepends ... in the Austrian case there is no real database, so it is something thatis very dynamic, and in construction, and that makes it more fascinating for someaspects but also more difficult to find common elements. But for the thematic part Ithink we will be able to find many common elements (...)” Entrevistado B

“There is a lot of work to do, everyone does their organizations project, the questionis how ... it’s been years that I work on it. It’ s not easy, but it’s more a political thana technical question (...). We need people willing to make concessions - Oh that’ssomething of my bussiness: I do not want to change so we can work together. Butthe problem still remains: how are we going to classify information together. And itis the same problem in France. There is the international level and the National level(France) ... to find a compromise is something very difficult.“ Entrevistado D

”(...) VIVIR BIEN is quite informal, also in the RIPESS project we are not reallycompatible, because you have huge institutions like in Italy and France, and VI-VIR BIEN we’re really just, you know, very informal, and we want to stay this wayand we don’t want to institutionalize.” Entrevistado F

Verificamos algo que foi encontrado na revisão da literatura: a diversidade da comunidadede ESS. Este facto traz à luz a necessidade de definição de limites claros para o contexto detrabalho.

A terceira conclusão é que os sistemas de informação da ESS tem um conjunto de informaçõesque podemos categorizar em três tipos:



1. informação que tem a ver com o registo de uma organização de ESS na plataforma e todoo processo de admissão (workflow) no sistema de informação:

“(...) they come to the platform and as you see there is a “Je veux me référencer”the organization clicks here and actually the first page is the charter, we have acharter that you can also find and read in the main menu, it is the last one ofthe buttons, called “Charte” (charter) (...) the organization or initiative has toaccept this charter and after they create an account and they can fill in the “fiched’initiative” and after we receive an email that we have a new “référencement”on the website. And we have regular meetings with the steering committee. Thecommittee consists of leaders of six organizations. We sit together and discuss,based on the charter, if the newly registered initiative can really be consideredas part of SSE or not.” Entrevistado C

“Here are only organizations that are associated with a network, a network(REAS network) of SSE. It is the network that opens a profile in its own space,not the organization, the organization must first be within the network, thenetwork is there in your territory.” Entrevistado E

“This is what they filled in when they registered. A bit of their activity, whatthey sell, describe the enterprise, then what kind of buying groups or fair tradeshops or farmer markets you sell in. (...) And then if its certified, that you haveseen, if it is (...) member of other organizations, and then comes the part of whyit is a Solidarity Economy organization. So we have one set of questions, these 5questions which they have to fill in, which are excluding the worst forms of “badeconomy”, let’s say. So they have to declare that they don’t do these things.”Entrevistado B

2. informação relacionada com a comercialização de produtos e serviços. Esta área com umfuturo mercado virtual de organizações de ESS onde: a) consumidores finais poderão acedera/comprar produtos e serviços (e-shop - Business to Consumer B2C), e b) as organizaçõesde ESS poderão encontrar parceiros de negócio (um e-marketplace de ESS - Business toBusiness B2B):

“In ZOES there is a section called buon mercato that means good market, whichis the e-commerce part.” Entrevistado B

“(...) We speak of having a catalog of SSE products/services and later we willhave an e-commerce SSE platform. Not yet, because there are things that are verylocal and very service-based, but yes we want to open an e-commerce platformin the future.” Entrevistado E

“We work, in Québec, on a project called “Commerce Solidaire” (solidaritycommerce), it is to create buying groups and also to make online transactions,so it’s a project that develops slowly, which should be online soon (...). Thesite that you saw earlier, the catalog of products and services that will enable



e-commerce, that is to say, to make online transactions, so we have that modelthat is being developed, that will be specific to companies of the solidarityeconomy.” Entrevistado A

3. informação relacionada com actividades, por tópicos:

“The idea is that you can interact with the companies, the enterprises in a socialnetwork kind, so they also have a profile, and they have to/ can reply and post,and use it as an individual, but it is a enterprise and therefore other users canhave an opinion of that enterprise and exchange ideas as well and it becomes away of not just having an on-line store, but getting more, I mean the whole ideaof SE is that you get to know the producer and enter in a trust relationship andthat relationship is by direct contact, usually direct contact is that you see theother one in the face but that is not always possible, so ZOES helps to establisha relationship.” Entrevistado B

A quarta conclusão é a de que as organizações de ESS não desejam ficar fechadas na sua ilha deinteroperabilidade Baptista (2010). Usando ainda a imagem da galáxia, as organizações de ESSdesejam partilhar informação com organizações fora da sua galáxia. Estão dispostos a tornardisponível informação sua para utilização de outros sistemas de informação de organizações quenão fazem parte da ESS:

“But there are many sites in France who do, in France there are hundreds andhundreds of sites, including on the issue of product sales, there are (. . . ) 10 20 30specialized sites already (. . . ) there are those that are close to the SSE (...) here in(http://www.eco-sapiens.com), they also do a lot of education and awareness, you see,a guide to ethical shopping, you can buy, bricolage, baby (...).” Entrevistado D

“I am sure because one of the aims of the project was already to be able to provide sta-tistical data towards the government, regarding SSE in Luxembourg.” EntrevistadoC

Uma sistematização da informação recolhida nas entrevistas está disponível em ApêndiceSecção B.1.2, Tabela B.3.

6.2.2.4.3 Resultados - Sistemas de Informação Web da Econonomia Social e Soli-dária

Após a realização das entrevistas, e para completar o estudo complementar necessário paracolmatar a lacuna revelada pela revisão de literatura, analisamos, do ponto de vista do utilizador,os SIW das organizações de ESS. Este estudo foi dividido em duas partes como já referido nasecção 6.2.2.2.3.

A primeira parte da análise é apresentada num quadro resumo no Apêndice A.Nas secções seguintes apresentamos a segunda parte da análise, que é feita aos SIW das

organizações que estão comprometidas com o mapeamento das organizações de ESS. Essa análise



apresenta a situação em cada organização/país relativamente ao panorama de ESS e relativamenteaos respectivos SIW.

Itália: ZOESO SIW “Zona Equosostenible” (ZOES)33 é um portal para redes sociais, referência geografica etemática da ESS em Itália. Este SIW foi criado e é mantido pela ”Fondazione Culturale BancaEtica”34.

Este SIW é uma plataforma de suporte à actividade das organizações nele resgistadas. Asorganizações nela presentes têm de ser certificadas por uma agência italiana de certificação deESS e são recomendadas por uma organização já presente no SIW. Além disso, passam porum processo simples de triagem,através do preenchimento de um formulário online. Caso sejarespondido “não” a uma das cinco primeiras perguntas, a organização é imediatamente eliminada.Na tabela 6.3 estão listados os seus parâmetros.

Tabela 6.3: Características do Sistemas de Informação Web zoes.it | Itália

Funcionalidade Sim/Não ObservaçõesCatálogo NãoComércio Electrónico NãoMapeamento SimTemáticas SimNotícias SimAcontecimentos SimBlog SimRede Social SimRSS NãoTAG Sim 1 nívelMetadados Não

Acrescentamos que o catálogo de produtos e serviços e a funcionalidade de comércio electróniconão está presente no SIW ZOES mas está no SIW http://www.buonmercato.org com a parti-cularidade de ter a funcionalidade de “preço transparente”, uma forma de mostrar ao consumidorfinal os custos parciais (logística, produção, etc) do produto que está a visualizar/comprar.

Verificamos que houve uma opção política ou estratégica de não incluir a componentede comércio electrónico (catálogo de produtos ou serviços e venda em linha) neste SIW. Amesma opção foi tomada no Québec (ver secção 6.2.2.4.3). A opção foi construir um portaltotalmente dedicado ao comércio electrónico, no entanto com especificidades da ESS. No portalhttp://www.buonmercato.org35 podemos encontrar as funcionalidades comuns de uma loja decomércio electrónico com duas particularidades:

• as organizações presentes no portal são identificadas como sendo parte da ESS. Possuemum resumo de apresentação tendo como ênfase as boas práticas (ambiente, de trabalho,

33Zona eco-sustentável - http://www.zoes.it - acedido em Junho 201134Fundação Cultural Banca Ética35Acedido em Junho 2011


http://www.buonmercato.org

http://www.buonmercato.org

http://www.zoes.it


etc.) Seguem os mesmos critérios de escolha do portal ZOES;

• existe o “preço transparente”, cada produto tem a identificação de como o preço do produtoé calculado (ex: custos da matéria prima, custos de transformação, custos de logística,etc.).

Também neste portal de comércio electrónico está presente o mapeamento das organizações.Existe um conjunto de informações muito específicas à ESS que estão disponíveis na ficha

da Organização. Além disso existem funcionalidades que permitem o desenvolvimento de redesdentro do SIW, e a possibilidade de se definir como um especialista numa determinada área deconhecimento para a possibilidade de ser contactado directamente por um consumidor.

Verificamos então que o SIW ZOES para além de vender produtos e serviços (através doBuon Mercato), ele é um espaço de trabalho e promoção da ESS. Existe um conjunto defuncionalidades que estão catalogadas em 10 temas distintos. Estas funcionalidades são aoferta de emprego, os livros editados, os documentos, a ligação às entidades que se cataloga-ram dentro dessas temáticas, para além dos tradicionais notícias, eventos, acontecimentos e forum.

França: La BDISO “Mouvement pour la Économia Solidaire“36 (MES) é o responsável pela criação e manutençãoda SIW La BDIS 37. Este SIW mapeia as organizações de ESS em França mas não suporte a suaactividade. Cada organização de ESS está identificada no mapa e tem a sua ficha disponível.

Na Tabela 6.4 estão listados os parâmetros do SIW BDIS.

Tabela 6.4: Características do Sistemas de Informação Web la-bdis.org | França

Funcionalidade Sim/Não Observações.Catálogo NãoComércio Electrónico NãoMapeamento SimTemáticas NãoNotícias NãoAcontecimentos NãoBlog NãoRede Social NãoRSS NãoTAG NãoMetadados Sim Description

O caso Francês é o caso mais complexo pela dispersão da sua organização no terreno. Háoutras organizações ”chapéu” que regrupam organizações irmãs da ESS no entanto não cabemnos critérios de ESS do MES, que têm a ver com:

• a sua identidade;36Movimento para a economia Solidária: http://www.le-mes.org) - acedido a 21 Janeiro 2014.37http://la-bdis.org - acedido em Junho 2011. A 21 Janeiro 2013 o URL já não estava acessível. No entanto

a ferramenta la bdis funciona embutida no site do MES em http://www.le-mes.org/Consulter-la-BDIS.html.


http://www.le-mes.org)

http://la-bdis.org

http://www.le-mes.org/Consulter-la-BDIS.html


• os valores da ESS;• os compromissos.Foi elaborada uma carta de princípios (contendo 4 princípios) que é assinada pelas organizações

quando se inscrevem no mapeamento da BDIS. O MES é o único movimento francês inscrito noRIPESS e é essa a razão pela qual será elemento do nosso estudo.

A ficha de inscrição na BDIS contém os seguintes elementos:• Identidade da organização: sigla, endereço, telefone, fax, email, sítio Web, contactos;• Organização: estatuto, número de assalariados;• Objectivos e actividades: objectivos, apresentação utilidade social;• Território e utilizadores: zona de intervenção, lugar de distribuição, tipo de utilizadores;• Parceiros : redes associadas, parceiros financeiros e actividades;• Fileiras económicas : fileiras, actividades, famílias da ESS, outras classificações;• Dados financeiros: orçamento, parte de auto-financiamento, valorização do voluntariado;• Modo de governança : instâncias dirigentes, modos de decisão;• Competências, recursos, temas de reflexão: trocas, mutualismos.

Luxemburgo: ECOSOLUXO “Institut Européen de l’Economie Solidaire“38 criou o SIW ECOSOLUX39 com o objectivo dedesenvolver a Economia Solidária no Luxemburgo. Neste SIW só estão presentes iniciativas ouorganizações que sejam seleccionadas por um comité de pilotagem. A ficha de registo tem osseguintes elementos:

• Dados da iniciativa (organização): nome, morada, telefone, fax, sítio Web, email;• Dados organizacionais: estrutura, objecto social, estatuto jurídico, presidente e responsável,

Número de assalariados, número de voluntários, número de homens e de mulheres, orçamentoanual, modos de financiamento, ano de criação;

• Dados relativos aos compromissos: social, ambiental, cultural, gestão democrática, econo-micos, solidariedade;

• Dados relativos aos produtos/serviços: Nome, descrição, pessoa responsável, tipo de venda,informações complementares à venda, ligação para o catálogo;

• Dados relativos à actividade: tipo de actividades;• Dados relativos à cooperação: projectos, redes, parceiros, necessidades.Na Tabela 6.5 estão listados os parâmetros do SIW ECOSOLUX.O SIW tem, para além do mapeamento com as fichas de organizações ou iniciativas de ESS,

um espaço de notícias e eventos. As organizações podem registar-se, seguindo o processo referidoanteriomente, e depois de aceites no sistema, podem alterar ou actualizar a informação nas suasfichas. Podem sugerir acontecmentos ou notícias, mas estas são colocadas pelos responsáveis doSIW.

Espanha: Portal de Economia Solidária

38Instituto Europeu de Economia Solidária.39http://www.ecosolux.lu/ - acedido a 21 Janeiro 2014.


http://www.ecosolux.lu/


A “Red de redes de Economia Alternativa y Solidária”40 é uma rede de redes espanhola que seorganiza por região. Esta organização é responsável pelo SIW Eonomia Solidária 41. Na Tabela6.6 estão listados os parâmetros.

Para estarem registadas no SIW, as organizações de ESS têm de fazer parte de uma REASregional. Os dados presentes na ficha de entidade são:

• Nossa actividade: redes a que pertence, sector, misão, produtos e serviços, outras redes,âmbito e horário de atendimento;

• Direcção e contacto: pessoa de contacto, correio electrónico, direcção, localidade e códigopostal, província, mapeamento Google, telefones, sítio Web;

• Imagem;• Outros dados: forma jurídica, nome jurídico, ano de início da experiência e ano deconstituição;

• Fichas de boas práticas.Este SIW tem como particularidade o facto de ter fichas de boas práticas (ambientais, econó-

40Rede de redes de economia alternativa e solidária.41http://www.economiasolidaria.org - acedido a 21 Janeiro 2014

Tabela 6.5: Características do Sistemas de Informação Web ecocolux.lu | Luxemburgo

Funcionalidade Sim/NãoCatálogo NãoComércio Electrónico NãoMapeamento SimTemáticas NãoNotícias SimAcontecimentos SimBlog NãoRede Social NãoRSS NãoTAG NãoMetadados Não

Tabela 6.6: Características do Sistemas de Informação Web economiasolidaria.org | Espanha

Funcionalidade Sim/Não ObservaçõesCatálogo NãoComércio Electrónico NãoMapeamento NãoTemáticas NãoNotícias SimAcontecimentos SimBlog SimRede Social NãoRSS NãoTAG Sim 1 nívelMetadados Não


http://www.economiasolidaria.org


micas, etc) muito completas, onde além de textos descritivos existem elementos de multimédia(sobretudo vídeos) realizados pelas organizações para partilha de saber. As fichas de boas práticastêm os seguintes campos :

• Boas práticas: princípio, objectivos, sector de actividade;• Entidades: entidades que participam, sítio Web da entidade;• Lugar e data;• Principal: tema, descrição, resultados, análise e avaliação, lições para aprender;• contacto;• fotos.

As organizações REAS podem actualizar as suas fichas (de entidade e de boas práticas),inserir conteúdos (documentos, notícias, actividades, bibliografia, vídeos) e catalogá-los com umTAG.

O SIW REAS partilha notícias (as notícias que são catalogadas em TAGs) com outros doisportais, nomeadamente o site do Forum Brasileiro de Economia Solidária e o site REAS daAmérica Latina e Caraíbas. Esta troca de dados é efectuada através de sinais RSS que estãoorganizadas também em TAGs.

Austria: Vivir BienO caso da Austria é muito particular. Por se tratar de um país onde o Estado Social é muitoforte, a ESS é definida como algo à margem do status quo da sociedade. O SIW Vivir Bien42

não está associada a nenhuma organização formal, são então indivíduos que se organizam e quevoluntariamente gerem o SIW, ao contrário de todas as outros SIW já referidos e ainda porreferir, que são geridos por uma organização formal, que existe juridicamente, e que representaoficialmente o conjunto das redes de ESS do seu país. Esta informalidade do ViVir Bien estápatente em todo o projecto já que na realidade este não está definido no sentido que existemobjectivos a atingir, definidos por orgãos de gestão ou de direcção da organização. As organizaçõesou indivíduos que estão registados no SIW entram somente com o convite de alguém que já estejaregistado no SIW - é a única forma de controlo existente (sobretudo para evitar SPAM). Nãohá nada a ser aceite, nenhum comité de controlo, nenhuma ficha de inscrição, à semelhança dosexemplos já apresentados. O SIW é gerido através de recursos: cada recurso tem um predicadoe um objecto. O software é composto por um conjunto de recursos, que podem ser inseridospor qualquer utlizador sem qualquer limitação. O recurso pode ser qualquer coisa, como porexemplo uma feira, uma loja, uma oferta de pão numa padaria. Esse recurso tem informaçãoassociada. Este SIW é então um conjunto de recursos com informação, recursos estes mapeadose organizados em temáticas.

Na Tabela 6.7 estão listadas as funcionalidades do SIW Vivir Bien.

Canadá: Économie Sociale Québec

42http://vivirbien.mediavirus.org - acedido a 21 Janeiro 2014.


http://vivirbien.mediavirus.org


O “Chantier pour l’Économie Sociale”43 é o responsável pelo SIW Économie Sociale Québec44.Este SIW está organizado por sectores de actividade, onde cada sector tem os elementos comuns:

• Artigos;• Documentos;• Fichas de organizações;• Cronicas;• Notícias;• Produtos;• Serviços;• Ofertas de emprego.

Os produtos e serviços são apresentados mas não existe efectivamente comércio electrónico. Àsemelhança do caso ZOES o comércio electrónico é efectuado noutro SIW (mas utilizando amesma base de dados do SIW economiesocialquebec.ca) http://achatsolidaire.com, ondeprodutos ou serviços da ESS no Québec estão disponíveis para venda.

As fichas de organização têm os seguintes elementos:• Nome, morada, telefones, fax, correio electrónico, sítio Web;• Missão, descrição, horários;• Contactos;• Comunicados;• Actividades e acontecimentos;• Serviços e produtos;• Cartografia (referência no mapa Google).As organizações que estão neste SIW são controladas apenas através do seu estatuto jurídico.

Há no entanto um controlo mais apertado, no caso de dúvidas, através dos pólos regionais doChantier.

Na Tabela 6.8 estão listados os parâmetros existentes no SIW Économie Sociale Québec.43Oficina para a economia social.44http://www.economiesocialequebec.ca - acedido a 21 Janeiro 2014.

Tabela 6.7: Características do Sistemas de Informação Web vivirbien.mediavirus.org | Austria

Funcionalidade Sim/Não ObservaçõesCatálogo SimComércio Electrónico NãoMapeamento SimTemáticas SimNotícias SimAcontecimentos SimBlog NãoRede Social NãoRSS NãoTAG Sim InfinitoMetadados Não


http://achatsolidaire.com

http://www.economiesocialequebec.ca


Verificamos que, à semelhança do caso ZOES houve uma opção política ou estratégica denão incluir a componente de comércio electrónico (catálogo de produtos ou serviços e venda emlinha) nesta SIW. Ele existe em http://www.achatsolidaire.org. Este portal de comercioelectrónico tem a particularidade de possuir a funcionalidade de banca de pedidos e banca deofertas.

Este SIW é uma plataforma de suporte à actividade das organizações aí referenciadas, ondeelas podem autenticar-se e introduzir conteúdos, actividades, notícias e documentos.

Brasil: CirandasO Forum brasileiro para a Economia Solidária é o responsável pelo desenvolvimento e manutençãodo SIW Cirandas45. Este site é o SIW de ESS com maior dimensão a nível mundial, ele reúnemilhares de organizações (empreendimentos é o termo usado), grupos informais de pessoas(comunidades é o termo usado) e indivíduos (pessoas é o termo usado) que praticam ESS noBrasil. Na Tabela 6.9 estão listados os seus parâmetros.

45http://cirandas.net - acedido a 21 Janeiro 2014

Tabela 6.8: Características do Sistemas de Informação Web economiesocialequebec.ca | Canada

Funcionalidade Sim/Não ObservaçõesCatálogo SimComércio Electrónico NãoMapeamento SimTemáticas SimNotícias SimAcontecimentos SimBlog NãoRede Social NãoRSS NãoTAG Não NãoMetadados Sim Description;Keywords

Tabela 6.9: Características do Sistemas de Informação Web cirandas.net | Brasil

Funcionalidade Sim/Não ObservaçõesCatálogo SimComércio Electrónico NãoMapeamento SimTemáticas SimNotícias SimAcontecimentos SimBlog SimRede Social SimRSS SimTAG Sim 1 nívelMetadados Sim Description


http://www.achatsolidaire.org

http://cirandas.net


Este SIW foi desenvolvido especificamente para desenvolver redes sociais. Por isso, desde asua génese, tem ferramentas para potenciar essa possibilidade: blog, chat privado e público, redes(de pessoas, de comunidades, de empreendimentos). Os empreendimentos têm um espaço paraapresentar o seu catálogo de produtos e serviços, através de um perfil, nesse perfil apresentam-seos seguintes dados e funcionalidades:

• Quem somos;• Nossos produtos;• Pontos de venda;• Galeria de imagens;• Fale connosco (possibilidade de envio de email para o empreendimento);• Localização no mapa Google.Além disso, através da categorização transversal existente no SIW, é possível encontrar pes-

soas, empreendimentos, comunidades, produtos, artigos e acontecimentos que se auto catalogaramcom as temáticas desejadas. Mais uma vez uma funcionalidade semelhante à existente no SIWZOES (ver secção 6.2.2.4.3), grande gerador de comunidade, já que se geram lugares não sóde procura de possíveis parceiros de cadeias produtivas ou de criação de redes sectoriais (porafinidades ou por opções políticas e de valores) mas também de consolidação de redes ou cadeiasprodutivas já existentes. Aqui podemos ver que o Cirandas pode, nesta potencialidade, criarredes que sem o apoio desta ferramenta seriam extremamente impossíveis de existir devido àsdistâncias geográficas ou dificuldade de comunicação.

OutrosOutros SIW existem no mundo inteiro. Na Alemanha, na região de Nord-Hessen foi desenvolvidoum projecto de cartografia no âmbito de um projecto Universitário. O resultado pode serconsultado em http://www.kmfn.de/rnf46. Este projecto terminou e não está a ser actualizado.Outro SIW existente e com potencial é o sistema Solidarius http://www.solidarius.org.br46

que tem objectivos distintos a todas os sistemas e organizações até ao momento abordados. Éum sistema para desenvolver actividades de indivíduos, comundidades ou organizações. Tem noentanto a particularidade de ter uma moeda virtual, que tem correspondência com as moedasreais através do cálculo de uma fórmula desenvolvida pelos responsáveis do projecto Solidarius.Este projecto tem uma grande dimensão e é utilizado em 6 países.

Trata-se de um projecto muito específico de ESS, totalmente à margem da economia demercado (não é possível vender produtos fora do sistema), ao contrário dos projectos anteriores,que podem encaixar-se na economia de mercado.

Outros SIW existem ainda mas estão muito pouco desenvolvidos, de momento não fazemparte do consórcio; nenhum deles tem mapeamento e poucos têm ferramentas de desenvolvimentode redes sociais. São sobretudo sistemas de informação e exposição de produtos/serviços. Elessão:

• Chile: http://redeconomiasolidaria.com47

46Acedido em Junho 201147Acedido em Junho 2011.


http://www.kmfn.de/rnf

http://www.solidarius.org.br

http://redeconomiasolidaria.com


• Peru: http://gresp.org.pe47

• Uruguai: http://www.comerciojustouruguay.com47

• Ásia48: http://aa4se.com49

No continente Africano não existe, à data da escrita desta proposta e tanto quanto é do nossoconhecimento, nenhum SIW para a ESS.

6.2.2.4.4 Considerações finaisVerificamos que há uma organização muito forte na ESS a nível mundial. Os SIW revelam

claramente a força dessa organização, mimetizando as redes locais, regionais e sectoriais.Os SIW Cirandas no Brasil, ZOES em Itália, Chantier pour l’économie Social no Canadá-

-Québec e Portal da Economia Solidária em Espanha são notoriamente os sistemas mais evoluídosno estado da arte dos SIW de ESS no mundo pela informação que disponibilizam aos utilizadoresfinais e pelas interacções que os utilizadores/organizações de ESS podem ter quando utilizam oseu espaço no SIW para apresentar as suas organizações.

No Brasil sente-se uma preocupação de fomentar e sedimentar as interacções ao colocar asiniciativas ou organizações de ESS em contacto através de um software fortemente vocacionadopara a construção de rede social. Isso é visível na existência da possibilidade de criação de“comunidades virtuais” de pessoas ou de empreendimentos.

De salientar que, apesar de existirem iniciativas de ESS nos cinco continentes, apenas umconjunto muito pequeno de organizações possui SIW para organizar o seu trabalho no terreno.De salientar ainda que o facto de não existirem SIW para alguns continentes/países, não significaque nesses continentes/países a ESS não esteja organizada no terreno; significa que por algumarazão (organizacional, política, económica ou outra) ainda não desenvolveram ferramenta desuporte na Internet. Não são os objectivos deste trabalho entender a razão deste facto. É noentanto importante referi-lo, porque a relevância do trabalho que nos propomos fazer é tantomaior quanto a dimensão do potencial da utilização dos seus resultados.

Do estudo sobre ESS e SIW efectuado podemos verificar que a comunidade mundial de ESS éum caso muito particular de fazer economia, o seu objectivo não reside no lucro. As actividadesde ESS que envolvem efectivamente transacções de produtos e serviços, trazem com elas umconjunto de princípios que as tornam um espaço distinto da economia de mercado. As redes queexistem e as informações que se trocam entre essas redes são importantes motores da actividadede ESS. Estas fazem-se num espaço de cuidado e de respeito pelo indivíduo, pela sociedade epelo planeta. A grande distinção entre a economia de mercado e a ESS é que a primeira temo comércio como grande objectivo, e a segunda tem também a relação de trabalho colaborativobaseado na dádiva e partilha. Esta dimensão relação tem um papel muito importante na ESS nocontexto da transacção comercial pois a ESS não se esgota na mera relação económica. Podemosdizer que:

48A unidade de análise tem sido o país, aqui abre-se a excepção por não existir nenhum país, tanto quantoconseguimos apurar, com SIW na Ásia, por não existir nenhum SIW que apoie a actividade da comunidade deESS na Ásia. Este site referido é o único site da comunidade de ESS Asiática.

49Acedido em Junho 2011. A 3 de Abril de 2014 este sítio Web já não existe.


http://gresp.org.pe

http://www.comerciojustouruguay.com

http://aa4se.com


A dimensão comérciocontém informação particular ao contexto: verificamos que há dados na ESS, não existentesno comércio da economia de mercado, que é necessário identificar.

A dimensão relaçãotransporta informação muito relevante para as actividades de ESS: verificamos que hádados, nomeadamente sobre as instituições e processos, e sobre as temáticas (notícias eacontecimentos, por exemplo) de ESS que precisam de ser capturados.

Vimos (c.f. secção 6.2.2.4.2) que os líderes tecnológicos da comunidade de ESS têm comoobjectivo o fortalecimento das suas redes, existentes já no terreno há alguns anos, utilizandosistemas de informação inter-operáveis, partilhando semanticamente informação. Isso está longede acontecer. O debate que realizam é hoje finalmente a concretização de uma organizaçãointerna (nacional) e externa (a nível internacional) de partilha de informações e de procura deentendimentos. Constatámos através deste estudo que o consórcio não tem ainda claro a formacomo pode desenvolver interoperabilidade nos seus SIW. Ele deseja que os SIW de cada parceiro- que são distintos, com esquemas de dados diferentes, e que foram criados à medida e dimensãode cada um dos parceiros - partilhem informação semântica de forma a utilizar a informaçãoem proveito do consórcio, em proveito de toda a comunidade ESS e em proveito de comunidadeexternas à sua. De facto o termo ”interoperabilidade“ não envolve somente aspectos tecnológicosIDABC (2004). Os aspectos organizativos não podem ser esquecidos, são na realidade partemuito importante de um projecto de implementação de interoperabilidade. Isto ficou claro nareunião de Paris (c.f. Apêndice B.1.1), onde se verificou a dificuldade de entendimento entre ospresentes. De facto, nem todos têm a mesma informação disponível, nem todos usam a mesmaterminologia e nem todos querem partilhar a mesma informação.

As questões que se colocam neste momento são:1. O que deseja partilhar esta comunidade?2. Com quem deseja partilhar?Relativamente ao primeiro ponto verificamos, das entrevistas e do estudo dos SIW, que há

um conjunto de dimensões que existem em comum mas que necessitam de um estudo maisaprofundado, e de tratamento de forma a poderem ser processáveis pelas máquinas.

Relativamente ao ponto dois, a partilha intra-comunidade é o primeiro objectivo. No entanto,verificamos também que há já uma intenção de trocar informação com a economia de mercado.

Para além desta possibilidade, de alcance dos sistemas de economia de mercado, há ainda ointeresse em pensar em outras comunidades que estão também “fora“ da galáxia da ESS, comopor exemplo organizações governamentais (e-government) - ver Figura 6.6.

É de enorme interesse que a comunidade de ESS possa dialogar, através dos seus SIW, comestas entidades externas à sua comunidade, permitindo assim tirar proveito do melhor que aabertura a outras realidades lhe possa trazer.

Seria ainda importante que os SIW da comunidade de ESS fossem repositórios de informaçãodisponíveis para a função de descoberta no paradigma da WS, de forma a poder ”cruzar fronteirasde descoberta“50 Duval et al. (2002).

50No original:“to cross discovery boundaries”.



Figura 6.6: Interfaces de interoperabilidade entre os Sistemas de Informação Web da EconomiaSocial e Solidária.

Para realizar esta interoperabilidade semântica, e posicionando-nos no contexto da WS, seránecessário que os SIW utilizem um DCAP que satisfaça as necessidades de descrição de recursosda ESS. Para entender se tal DCAP existe é necessário realizar um estudo aos PA da comunidadede metadados. Esse estudo foi realizado sendo o Environmental Scan (ver Secção 6.3.1).

6.2.3 Requisitos de alto-nível

• Person searching for SSE organizations (mandatory requirement);• Researcher looking for aggregate information on SSE (mandatory requirement);• Person searching for products (mandatory requirement);• SSE enterprise exchanges local information with the web (non mandatory requirement);• Public policy maker makes a public call to buy from or hire SSE enterprises (non mandatory

requirement).

6.2.4 Modelo de Casos-de-Uso

A equipe de trabalho de desenvolvimento do DCAP-ESS definiu 3 Casos-de-Uso.

Diagrama UML de Casos-de-UsoO Diagram UML de Casos-de-Uso é apresentado na Figura 6.7. Foram identificados três tipos deutilizadores: o utilizador comum, o investigador e o computador que está realizando descobertasna WS.

Casos-de-Uso Detalhados



Use-Case 1: Person Searching for SSE organizationsPre Conditions:

• User is connected to solidarity economy Web portal;• User knows what category of organization(s) he/she is looking for (category of organizationstill to be defined, probably more than one field connected to a controlled vocabulary);

• User knows what geography he/she is looking in (for example, Philadelphia or 5 kilometer-s/miles radius from Philadelphia);

Flow of events:Scenario A:

• User opens platform search engine;• User types in organizational type and geographical identifiers;• List of organizations of that category appear together with a map identifying their locationswithin the geography.

Scenario B:• User opens platform search engine;• Platform search engine includes drop-down menu or box listing different SSE organizationalcategories;

• Platform includes geographical identifiers (city, distance from city center);• User indicates geographical parameters and clicks on desired organizational category;• Platform generates a list of organizations of that category together with a map identifyingtheir locations within the geography;

• User is given option of ordering data by “Name”, “Proximity”, or “Organizational category”.For Both Scenarios:

• User given option to download data;• User indicates that she/he would like to download data;• User selects type of file for download (for example, XLS, TXT, CSV, Other?);• Downloaded file presents list of organizations organized by with:

– Name– Organizational category;– Addresses (separate cells for street number, city, state/province, zip code, country);– Webaddress;– Phone;– Other information.

Use-Case 2: Researcher looking for aggregate dataPre Conditions:

• Researcher is connected to solidarity economy web portal;• Researcher knows what type of aggregate data he/she wishes to acquire.

Flow of events:• User indicates that she/he would like to download data;• User indicates geography for the report:

– Entire country;



Figure 6.7: Diagrama UML de Casos-de-Uso

– State/province;– City;– Miles/kms radius from city.

• User sets search parameters for report. This might include the set of all SSE organizationsof all types in chosen geography, or a subset of SSE organizations filtered according tosearch criteria;

• User indicates what variables to include in report:– Overall number of organizations;– Aggregate number of organizations divided according to:

∗ “organizational type” and/or;∗ economic sector and/or;∗ thematic criteria, and/or;∗ SSE qualifiers.

• User clicks enter;• Web portal creates summary report and allows for it to be downloaded as a PDF document.

Use-Case 3: Person searching for productsFlow of events:

• User types the search keywords into the search box;• User press “enter” or click the “search” button;• System presents the search results in many forms:

– List of most relevant products;



– List of categories (vocabulary or ontology);– Map with products location;– User can:

∗ Select a product, and is directed to the enterprises page;∗ Select a category, and browse the product tree.

6.2.5 Requisitos Funcionais

• Apoiar a pesquisa de qualquer, ou de todos os elementos: SSEInitiative, Network, Product,Sale Options e Product-Input (Caso-de-Uso 1, 2 e 3).

• Procurar por qualquer propriedade de cada elemento referido no ponto anterior e aindaCost Composition de qualquer Product-Input (Caso-de-Uso 1, 2 e 3).

• Providenciar metadados para a construção de informação estatística (Caso-de-Uso 2).

6.3 Desenvolver o Modelo de Domínio

A Secção 5.4 define que esta actividade composta desenvolve as actividades apresentadas naFigura 6.8. No final deverá produzir o artefacto Environmental Scan (c.f. Secção 6.3.1), e odeliverable Modelo de Domínio (c.f. Secção 6.3.2).

Figura 6.8: Diagrama de contexto da Etapa de Singapura: Desenvolver o Modelo de Domínio

6.3.1 Environmental Scan


Necessitamos saber se haverá algum DCAP que possa servir a comunidade ESS no sentido deimplementar interoperabilidade entre os seus SIW. De facto não encontramos nenhum estudo comuma revisão de todos os PA existentes na comunidade de metadados ou nenhum sítio Web quereunisse essa informação pelo que decidimos que era necessário realizar um tal estudo. O nossoobjectivo geral era o de entender o panorama dos PA existentes na comunidade de metadados.



No entanto, à medida que fomos recolhendo os dados para o estudo entendemos que poderíamosir mais longe com esses dados. O objectivo específico do estudo evolui no sentido de entender opanorama dos PA no que diz respeito a:

• quais os PA desenvolvidos até ao momento (ver Secção 6.3.1.3.1);• qual o tipo de instituições que desenvolveram PA (ver Secção 6.3.1.3.2);• quais os domínios de aplicação dos PA (ver Secção 6.3.1.3.3);• quais os esquemas de metadados utilizados pelos PA (ver Secção 6.3.1.3.4);• quais os domínios de aplicação que estão a produzir esquemas de metadados (ver Sec-ção 6.3.1.3.5);

• quais são os esquemas de codificação utilizados pelos PA (ver Secção 6.3.1.3.6);• qual o panorama da utilização do Enquadramento de Singapura por parte dos PA (verSecção 6.3.1.3.7).

Na secção seguinte apresentamos a metodologia de trabalho.

6.3.1.2 Metodologia de trabalho

6.3.1.2.1 Revisão de literatura e outros esforços de pesquisaForam efectuadas pesquisas bibliográficas com pesquisas gerais e depois refinadas nas bases dedados online. As bases de dados utilizadas foram o Google Scholar51, o ISI Web of Knowledge52,o SCI ETD Networked Digital Library of Thesis and Dissertations53, o Scopus54 e o Oaister55.

As pesquisas foram realizadas em Inglês, em Português, em Espanhol e em Francês noscampos “título do artigo” “Assunto do artigo” e “corpo do artigo”.

• Na primeira fase: foram retidos um conjunto de artigos;• Na segunda fase: das pesquisas, foram analisadas as referências dos artigos retidos naprimeira fase, seleccionando novos artigos pela relevância do título e mais tarde pelarelevância do sumário. O processo foi iterativo em relação aos novos artigos encontrados,terminando quando os artigos se referenciavam mutuamente;

• Na terceira fase: das pesquisas foram recuperados artigos que citavam os artigos basilares.Os novos artigos foram seleccionados segundo o mesmo critério referido na fase 2 dapesquisa.

As palavras chave introduzidas na pesquisa foram: Metadata Application Profile, Dublin CoreApplication Profile, Metadata Element Set, Metadata Scheme e Metadata vocabulary.

Para além desta revisão de literatura, onde foram encontrados artigos científicos reportando odesenvolvimento de PA ou DCAP, foram desenvolvidos esforços para encontrar PA não reportadosna comunidade científica através de:

• Pesquisas no Google com as mesma palavras chaves definidas na revisão de literaturaanteriormente referida;

51http://scholar.google.com - acedido em Junho de 2011.52http://www.isiWebofknowledge.com - acedido em Junho 2011.53http://www.ndltd.org/serviceproviders/scirus-etd-search - acedido em Junho 2011.54http://www.scopus.com - acedido em Junho 2011.55http://oaister.worldcat.org - acedido em Junho 2011.








• Posts na mailing list General da DCMI56 apelando ao envio de informação relativamente adesenvolvimento de PA;

• Informação existente na mailing-list Architecture da DCMI57.• Estudo da documentação técnica disponível dos perfis de aplicação. Estes apresentavam oestado da arte de perfis de aplicação da área de aplicação. Esse estado da arte trouxe ainformação de novos perfis de aplicação;

• Nãos casos onde não havia suficente informação nos sites ou nos artigos científicos, foramenviados emails aos autores dos artigos científicos ou aos contactos nos sítios Web a pedirdocumentação técnica.

6.3.1.2.2 Análise dos Perfis de AplicaçãoPara a realização da análise dos PA, foi seguida a metodologia de Manouselis et al. (2010):

incorporação de um conjunto de dimensões de análise em matrizes implementadas em OpenOffi-ce-Calc. A análise dos PA dividiu-se em 3 conjuntos de dimensões que são apresentadas já aseguir.Descrição do primeiro conjunto de dimensõesO primeiro conjunto de dimensões de análise têm a ver com informação sobre “nome” do PAo “ano” de desenvolvimento do PA, o “tipo de institiuição” que desenvolveu o PA, “domínio” e“sub-domínio” do PA, e a aferição do PA relativamente ao “Enquadramento de Singapura”:

• Acrónimo: Acrónimo dado ao PA;• Ano: Ano em que a versão do PA foi publicada. Esta informação foi retirada ou da

documentação técnica, ou no caso da ausência desta, do artigo científico, ou ainda, no casoda ausência deste último, da data de actualização da página Web com a informação do PA;

• Nome: Nome por extenso dado ao PA;• Tipo de Instituição: O tipo de instituição ou comunidade que desenvolve o PA. Fizemosuma categorização para este campo, ela está listada na Tabela 6.10;

• Domínio: Contexto, comunidade, área de aplicação a que o PA se destina. Fizemos umacategorização para este campo. Sempre que era encontrado mais do que um PA com ummesmo domínio de aplicação, era criada uma nova categoria. Não final, os PA que estavamisolados numa categoria de domínio de aplicação, eram colocados na categoria “Outros”. ATabela 6.11 apresenta a listagem das categorias de domínios;

• Sub-domínio: Um sub-domínio dentro da área mais transversal (ponto anterior) a que oPA se destina. Nem sempre este campo é preenchido, só quando é importante especificar,para distinção do domínio mãe. É também usada a categorização da Tabela 6.11;

• Versão: Versão do PA;• Singapura: Aferição do enquadramento de Singapura. Um PA segue o enquadramentode Singapura se define os Requisitos Funcionais, se define um Modelo de Domínio e seestá codificado em DSP (para saber mais sobre o Enquadramento de Singapura por favorconsultar Baker et al. (2008)). Se o PA segue o Enquadramento de Singapura o valor é

[email protected]@jiscmail.ac.uk



Tabela 6.10: Categorização do tipo de instituições ou comunidades que desenvolveram o Perfil deAplicação de metadados.

Tipo DescriçãoComunidade Científica Um projecto desenvolvido em uma

ou várias universidades.

Grupo Regional de Pessoas Um grupo de pessoas que trabalhano espaço físico de uma região de umpaís (por exemplo: Texas, Minho,Bretanha, Andaluzia).

Grupo Nacional de Pessoas Um grupo de pessoas que trabalhanum mesmo país.

Grupo Internacional de Pessoas Um conjunto de pessoas que trabalhaem diferentes países.

Governo Nacional Um Ministério ou qualquer outrotipo de instituição governamental.

Governo Internacional Um conjunto de governos de diferen-tes países ou governo federal (porexemplo: União Europeia; um con-junto de ministérios).

Organização/Empresa Regional Uma organização ou empresa a nívellocal.

Organização/Empresa Nacional Uma organização ou empresa quetrabalha a nível nacional.

Organização/Empresa Internacional Uma organização ou empresa compresença a nível mundial (por exem-plo: RIPESS, FAO).

Informação não disponível Quando não há informação sobre otipo de pessoas/organizações que de-senvolveram o Perfil de Aplicação.



Tabela 6.11: Categorização domínios de aplicação dos Perfis de Aplicação de metadados.

DomínioAgriculturaBibliotecas/RepositóriosCiênciaE-GovernmentMulti-domínioObjectos de aprendizagemPatrimónio CulturalOutros

“1”, caso contrário é “0”;• Baseado em: Esquemas de metadados em que o PA se baseia;• Novos termos: O uso por parte do PA de novos termos (adicionados aos esquemas de

metadados escolhidos - ver ponto anterior). Se existem, o valor usado é “1”, caso contrárioo valor usado é “0”;

• Binding: Tipo de ligação tecnológica disponibilizada. “XML” or “RDF”, se nenhum destes,utilizamos o valor “0”;

• FR: Requisitos funcionais (Functional Requirements), como definido no Enquadramento deSingapura. No caso de definir os requisitos funcionais do PA o valor é “1”, caso contrário ovalor é “0”;

• DM: Modelo de domínio (Domain Model) como definido no Enquadramento de Singapura.No caso de apresentar o modelo de domínio do PA o valor é “1”, caso contrário o valor é“0”;

• DSP: DSP, como definido no Enquadramento de Singapura. Se cada registo de metadadosdo PA estiver definido em DSP58 o valor é “1”, caso contrário o valor é “0”;

• Utilização: Guias de utilização. Se o PA tiver guias de utilização o valor é “1”, casocontrário o valor é “0”;

• Sintaxe: Guias de sintaxe. Se o PA tiver guias de sintaxe o valor é “1”, caso contrário ovalor é “0”;

• URL: Sítio Web com informações do PA; “n/a” caso não exista;• URI: URI descrição em RDF do PA; “n/a” caso não exista.

Descrição do segundo conjunto de dimensõesO segundo conjunto de dimensões diz respeito aos esquemas de metadados (também chamadosde vocabulários) base dos PA retidos.

Os esquemas de metadados foram categorizados (para a sua ordenação) segundo um conjuntode domínios que são apresentados na tabela 6.12).

O segundo conjunto de dimensões inclui:

58Ver Nilsson (2008).



• Acrónimo: Acrónimo do esquema de metadados;• Nome: Nome do esquema de metadados;• URL: URL do sítio Web com informações sobre o esquema de metadados. Usamos “n/a”quando não há informação sobre o sítio Web;

• URI: URI do documento RDF descrevendo o esquema de metadados. Usamos “n/a” quandonão encontramos nenhuma representação RDF do esquema de metadados.

Descrição do terceiro conjunto de dimensõesO terceiro conjunto de dimensões diz respeito aos esquemas de codificação de sintaxe e esquemasde codificação de vocabulário utilizados que foram utilizados pelos PA estudados. Uma vezque estamos a trabalhar no contexto da WS só registámos os esquemas de codificação que têmum URI dos documentos RDF descrevendo os esquemas de codificação. O terceiro conjunto dedimensões inclui:

• Nome: Nome do esquema;• Descrição: Descrição do esquema;• URI: URI do documento RDF descrevendo o esquema de codificação. Usamos “n/a” quandonão encontramos nenhuma representação RDF do esquema de codificação;

• URL: URL do sítio Web com informações sobre o esquema de metadados. Usamos “n/a”quando não há informação sobre o sítio Web.

6.3.1.2.3 Análise documentalA secção 6.3.1.2.1 revela termos encontrado um conjunto de documentos e sítios Web cominformação sobre PA. Estes documentos são artigos científicos, documentos técnicos e sítios Web.Alguns PA tinham estes três tipos de documentos disponíveis para consulta, outros só dois ou

Tabela 6.12: Categorização dos esquemas de metadados

DomínioAgriculturaAudio/Vídeo/MultimédiaBibliotecas/RepositóriosCiênciaColecçõesComércio ElectrónicoComunicação Científica, EditoresDescrição ou/e relações de/entre pessoas, comunidades ou organizaçõesE-GovernmentImagensMulti-domínioObjectos de aprendizagemPatrimónio CulturalOutros



mesmo só um. Analisamos estes documentos para obter informação sobre as três dimensõesdescritas. Os passos utilizados na análise documental foram:

• O ponto de partida para a análise foram os artigos científicos. Não caso de ser necessáriorecolher mais informação, usámos as referências existentes nos artigos para recolher maisinformação nos documentos técnicos, ou no sítio Web do PA. Quando nenhuma dasreferências trouxesse as informações necessárias, os autores dos artigos eram contactadospor email;

• Se não existissem artigos científicos de um determinado PA, apoiámo-nos nos documentostécnicos caso existissem e em último recurso, utilizámos os sítios Web do PA. Quando foinecessário enviámos emails aos contactos do sítio Web;

Nos casos em que não encontramos nenhum informação sobre uma determinada dimensãonas fontes anteriormente referidas, o valor usado no campo em questão foi “n/a”. A diferençaentre “n/a” e “0” é que a primeira significa que nenhuma informação foi encontrada apesar detodas as pesquisas efectuadas. A segunda significa que não existem que não foi definida - porexemplo se o DSP não foi encontrado nos documentos técnicos o valor foi definido como “0”.Os documentos técnicos existem e não referem tal variável. Por outro lado, no caso de não seencontrar documentos técnicos, o valor utilizado seria “n/a”.

6.3.1.3 Resultados

Seleccionamos um total de 83 PA, o mais antigo de 2001 e o mais recente de 2012. Contudo, 9dos PA encontrados foram excluídos do estudo pelas seguintes razões:

• Não havia informação relativa aos esquemas de metadados utilizados pelos PA;• Apesar de todos os esforços efectuados na secção 6.3.1.2.3, não foi possível encontrarinformação consistente sobre o PA;

• As definições do PA não eram públicas ou o que é chamado de PA não era de facto um,apresentando somente um esquema conceptual.

O Apêndice C.2 apresenta uma linha do tempo dos PA estudados59. Os resultados detalhadospodem ser consultados:

• Matriz I (primeiro conjunto de dimensões de análise) no Apêndice C.3;• Matriz II (segundo conjunto de dimensões de análise) no Apêndice C.4;• Matriz III (terceiro conjunto de dimensões de análise) no Apêndice C.5;• Esta informação está também disponível no handle http://hdl.handle.net/1822/23412,onde se encontra também um ficheiro com os datasets.

6.3.1.3.1 PA desenvolvidos até ao momento

Os PA analisados foram (listados por domínio de aplicação e por ordem alfabética):Agricultura

Ag-Event AP, Ag-Job AP, AGRIS, FiMES, Organisation AP59Esta linha foi elaborada pela aluna de mestrado Taciana Isabel Azevedo dos Santos, no âmbito da UC

Iniciação à Investigação em TSI do Mestrado de Sistemas de Informação.




Bibliotecas/RepositóriosDC-CDAP, DC-LIB, DRC AP, MAP, Michael-eu DCAP, MPEG21 DIDL, NLM MS,OAI-DC, RENAP, TDL ETD MOS

CiênciaAPIARY AP, DRYAD, MLAP, SWAP

E-GovernementADMS, DC-Gov, e-GMS, GO-WMES, OWMS, PSI AP

Multi-DomínioAudiovisual AP, AGLS, DC-EM AP, NZGLS, TBM-AP, VMAP

Objectos de AprendizagemAg-LR, ANZ LOM, AraCore, BEN, CanCore AP, Celebrate AP, CerOrganic AP, CG LOM,DC-Edu, Edna, FAILTE, FERL, HLSI, LOMAP, LORELOM, LRE AP, ManUel, MELT,MIMETA, Normetic, NORMLOM, OpenCartable, Organic Edu.net, ReGov, RLLOMAP,scoLOMFR, SCORM, TLF AP, UK LOM Core, Vedata

Património CulturalEDMMAG, EMAP, ESE, Folklore Description AP, PICO, QuinkMAp

OutrosCRAP, DC2AP, IAP, IOAP, OAI-ORE

Apresenta-se uma lista detalhada dos PA analisados com referência à fonte principal da informa-ção em apêndice C.1. Esta lista está organizada por domínio de aplicação e ordenada por ano, eem cada ano, por ordem alfabética.

6.3.1.3.2 Que tipo de instituições desenvolveram PAO cálculo da percentagem de PA por tipo de instituição (ver Tabela 6.13) mostra que os PA

são desenvolvidos na sua maior parte pelo grupo “Comunidade Científica” com 23 PA (31.1%),pelo grupo “Organização/Empresa Internacional” com 13 PA (17.6%), e pelo grupo “GovernoNacional” com 11 PA (14.9%). Estes 3 grupos produziram 63.5% do total dos PA estudados. Aseguir a estes grupos temos os grupos “Grupo Internacional de Pessoas”, “Grupo Nacional dePessoas”, “Organização/Empresa Nacional”, “Grupos Regional de Pessoas” que desenvolveramcada um deles 5 PA (6.8%); segue o grupo “Governo Internacional” com 2 PA (2.7%), e finalmenteo grupo “Organização/Empresa Regional” com 1 PA (1.50%). 4 PA (5.4%) não tinham qualquerinformação sobre as características das organizações que os desenvolveram.

6.3.1.3.3 Quais os domínios de aplicação dos PAO cálulo da percentagem de PA por domínio de aplicação (ver Tabela 6.14) mostra que o

domínio “Objectos de Aprendizagem” é o que mais produz PA; 31 dos 74 PA analisados (41.9%)pertencem a este domínio. O segundo maior produtor de PA é o domínio de “Bibliotecas/Re-positórios” com 10 PA (13.5%) produzidos, seguido do domínio “Património Cultural” com 7PA (9.5%) produzidos. Os domínios “E-Government” e “Multi-domínio” são o quarto maior



produtor de PA com 6 PA (8.1%) cada um, de seguida vem o domínio “Agricultura” com 5 PA(6.8%) produzidos. O domínio que menos produz é o domínio da “Ciência” com 4 PA (5.4%). Acategoria de domínio “Outros” possui 5 PA (6.6%) produzidos.

Muitos dos PA do domínio “Objectos de Aprendizagem” são um sub-conjunto do esquemade metadados “IEEE LOM”. Estes PA não fazem efectivamente uma “mistura e conjugação”Heery and Patel (2000) de esquemas de metadados mas mais um refinamento do padrão (nestecaso do “IEEE LOM”) materialisando o conceito mais antigo de um PA definido por Lynch (1997).

6.3.1.3.4 Quais os esquemas de metadados utilizados pelos PAAs análises revelaram a utilização de 52 esquemas de metadados distintos: ADL, Agent MT,

agls, agmes, Availability MT, Bibio, CDWA Lite, CLD, Darwin Core, dc, dc-lib, dc collections,dcterms, didl, dii, edna, eGMS, eprint, foaf, FRBR, GEM, GILS, GO-ITS, GovML, GOVTALK,IEEE LOM, IMS, JHS143, LIDO, LRE AP, MARC, MARCREL, METS, METS Rights, Michael,

Tabela 6.13: Percentagem dos Perfis de Aplicação de metadados por Tipo de Instituição.

% # Tipo de Instituição31.1% 23 Comunidade Científica17.6% 13 Organização/Empresa Internacional14.9% 11 Governo Nacional6.8% 5 Grupo Internacional de Pessoas6.8% 5 Group Nacional de Pessoas6.8% 5 Organização/Empresa Nacional6.8% 5 Grupo Regional de Pessoas2.7% 2 Governo Internacional1.4% 1 Organização/Empresa Regional5.4% 4 Informação não disponível100.0% 74 Total

Tabela 6.14: Percentagem dos Perfis de Aplicação de metadados por domínio.

% # Domínio de Aplicação41.9% 31 Objectos de Aprendizagem13.5% 10 Bibliotecas/Repositórios9.5% 7 Património Cultural8.1% 6 Multi-domínio8.1% 6 E-Government6.8% 5 Agricultura5.4% 4 Ciência6.8% 5 Outros

100.0% 74 Total



Mix, MODs, NISO, NZGLS, ORE, OWMS, pbcore, PRISM, rmes, remsq, RSLP, SCORM, SM,tbm, TextMD and Vcard.

Informação detalhada sobre estes esquemas pode ser consultada no Apêndice C.4.Houve PA que foram usados como esquemas de metadados por outros PA que são aqui

listados como esquemas de metadados apesar de, de acordo com a definição de Press (2004), nãoo serem.

Para entender quais foram os esquemas de metadados mais usados, calculamos o número devezes que cada esquema de metadados foi usado em cada PA estudado. Para fazer isso, paracada PA identificamos o esquema de metadados usado e adicionamos 1 à contagem daqueleesquema de metadados em particular - por exemplo o PA VMAP usa os elementos “dc.title”,“dc.identifier”, “dc.creator”, “dc.description” e “dc.subject”; adicionamos 1 ao esquema “DC”;também usa “foaf.firstName”; adicionamos 1 ao esquema “foaf”. Consulte a Tabela 6.15 para oresultado destes cálculos.

# % Esquema de Metadados

41 24.1% DC29 17.1% IEEE LOM26 15.3% DCTERMS6 3.5% agls5 2.9% foaf4 2.4% MODs3 1.8% AGMES3 1.8% IMS3 1.8% MARC3 1.8% Vcard2 1.2% Darwin Core2 1.2% DC Collections2 1.2% eprint2 1.2% FRBR2 1.2% LRE AP2 1.2% MARCREL2 1.2% MIX2 1.2% RSLP1 0.6% ADL1 0.6% Agent MT1 0.6% Availability MT1 0.6% Bibio1 0.6% CDWA Lite1 0.6% CLD1 0.6% DC-Lib

Continua...



Tabela 6.15: Continuação da página anterior

# % Esquema de Metadados

1 0.6% didl1 0.6% dii1 0.6% edna1 0.6% eGMS1 0.6% GILS1 0.6% GO-ITS1 0.6% GovML1 0.6% GOVTALK1 0.6% JHS1431 0.6% METS1 0.6% METS Rights1 0.6% Michael1 0.6% NISO1 0.6% NZGLS1 0.6% ore1 0.6% OWMS1 0.6% pbcore1 0.6% PRISM1 0.6% rmes1 0.6% rmesq1 0.6% SCORM1 0.6% SM1 0.6% tbm1 0.6% TextMDTabela 6.15: Percentagem de esquemas de metadados.

O esquema de metadados DC é o esquema mais usado com 24.1%, seguido do esquema IEEELOM com 17.1%. De seguida temos o esquema DCTERMS com 15.3%. agls é o quarto maisusado com 3.5%, o foaf segue este úlitmo com 2.9%, e o MODs segue com 2.4%, contudo apercentagem de uso destes 3 últimos está bem longe da percentagem de uso dos esquemas DC,IEEE LOM e DCTERMS. Os seguintes mais usados com 1.8% são agmes, IMS, MARC e Vcard.Seguidos da percentagem de 1.2% cada: Darwin Core, DC Collections, eprint, FRBR, LRE AP,MARCREL, MIX and RSLP. Todos os esquemas restantes têm uma utilização muito residual(0.6%).

Agrupando os esquemas DC e DCTERMS num só grupo a que chamaremos de “Dublin Core”,este grupo Dublin Core é utilizado por 39.4% do total dos PA, sendo portanto o grupo maisrepresentativo.. O esquema de metadados IEEE LOM o segundo mais usado (17.1%), no entantoeste valor de 17.1% pode ser influenciado pelo facto de o domínio “Objectos de Aprendizagem”



ser o maior “produtor” de PA (c.f. Tabela 6.14).Podemos ainda dizer que:• O IEEE LOM é o esquema mais referido em 27 dos 31 (87.1%) PA do domínio “Objectos

de Aprendizagem”, e em 19 (61.3%) destes 31 PA é o único esquema usado. IEEE LOM éum padrão muito importante para o domínio “Objectos de Aprendizagem”;

• O IEEE LOM só é usado em PA que são do domínio “Objectos de Aprendizagem”, não foiencontrado em nenhum PA fora deste domínio;

• O esquema de metadados Dublin Core é totalmente multi-domínio uma vez que é utilizadoem todos os domínios de aplicação, mesmo no de “Objectos de Aprendizagem” onde existeum forte domínio, como vimos, do esquema IEEE LOM;

• Uma vez que o esquema IEEE LOM tem muitas propriedades em comum com os esquemasDublin Core, e que este último é pioneiro na comunidade de metadados, podemos concluirque os esquemas de metadados Dublin Core são de facto os mais usados nesta comunidade.

6.3.1.3.5 Que domínios de aplicação estão a produzir esquemas de metadadosO cálculo da percentagem dos esquemas de metadados encontrados nos 74 PA produzidos em

cada domínio de aplicação - c.f. Tabela 6.16 - revelou que o domínio “Bibliotecas/Repositórios”é o que mais contribui para a produção de esquemas de metadados tendo 21.6% do total dosesquemas encontrados. O domínio “Colecções” é o segundo maior produtor com 13.7%; osdomínios “Multi-domínio” e “E-Government” são os terceiros maiores produtores com 11.8%cada um. Depois destes quatro primeiros produtores de esquemas de metadados temos o domínio“Objectos de Aprendizagem” com 7.8%, o domínio “Audio/Vídeo/Multimédia” e “Descrição ou/erelação de/entre Pessoas, Comunidades ou Organizações” com 5.9% cada, seguidos dos domínios“Património Cultural”, “Imagens” e “Comunicação Científica/Editores” com 3.9% cada. Osdomínios que menos produzem esquemas de metadados são “Agricultura”, “Comércio Electrónico”e “Ciência” com 2.0% cada.

6.3.1.3.6 Quais os esquemas de codificação utilizados pelos PAFizemos uma análise dos esquemas de codificação utilizados nos PA encontrados.Encontramos 13 esquemas de codificação de sintaxe distintos: AGLS Availability , AGLS

Agent, DCMI Point, DCMI Box, DCMi Period, ISO 3166-1, ISO 3166-2, ISO 639-2, RFC 1766,RFC 3066, RFC 4646, URI, W3C-DTF.

Encontramos 90 esquemas de codificação de vocabulário distintos: DCMI Type Vocabulary,DDC, IMT, Info-eu-repo, LCC, LCSH, LCNAF, MeSH, NLM, TGN, UDC, AGLS Service, AGLSDocument, AGLS Jurisdiction, AGLS Audience, PRONOM, VMAP MusicEntity Type, VMAPMusicalFormType, VMAP MusicGenreType , VMAP TargetedStudent, VMAP MusicStyleType,VMAP Tonality, VMAP rhythmType, VMAP scoreType, VMAP documentType, VMAP lear-ningModality, VMAP classType, VMAP educationLevelType, VMAP conferenceType, VMAPconferenceTopic, VMAP musicPerformanceType, VMAP productionType, VMAP sourceFor-matType, VMAP colorType, VMAP directionType, VMAP conservationStateType, VMAP



scoreFormatType, VMAP keyType, VMAP keyModeType, VMAP recordStatusType, EprintEntity Type Vocabulary, Eprint Access Rights, Eprint Status, Eprint Type, Darwin Core TypeVocabulary, AGROVOC, Thesaurus for the Social Sciences, Eurovoc, The National AgriculturalLibrary’s Agricultural Thesaurus, STW Thesaurus for Economics, DBPEDIA, CC REL, ISAcore location vocabulary, ISA core person vocabulary, ISA core business vocabulary, DublinCore Collection Description Accrual Method Vocabulary , Dublin Core Collection DescriptionFrequency Vocabulary, Dublin Core Collection Description Accrual Policy Vocabulary, AquaticScience and Fisheries Abstracts Thesaurus, BT, CABT, LEMB Thesaurus, NALT, MEDITAGRI,UNBIS Thesaurus, AGRIS Subject Categories, ASFAC Classification Scheme, CABI Codes,Global Forest Decimal Classification (GFDC), FAO Technical Knowledge Classification Scheme,Journal of Economic Literature - Classification system, Accession Number, Call Number, CO-DEN, DOI, International Patent Classification, International Standard Book Number - ISBN,International Standards Serial Number - ISSN, Linking International Standards Serial Number -ISSN-L, Job Number, Microfiche Number, Patent Number, Report Number, UK EducationalLevels – UKEL, FRAD User Tasks, FRBRer User Tasks, FRSAD User Tasks, DC2AP TypeVocabulary, DC2AP Format Vocabulary, Open Metadata Registry Status Vocabulary.

Informação detalhada pode ser consultada no Apêndice C.5.

6.3.1.3.7 Avaliação da utilização do Enquadramento de SingapuraPara avaliação da utilização do Enquadramento de Singapura quisemos simplesmente res-

ponder à questão:: foram os PA desenvolvidos respeitando as regras do Enquadramento deSingapura? Um PA respeita as regras do Enquadramento de Singapura se definiu Requisitos

Tabela 6.16: Percentagem de esquemas de metadados produzidos por domínio de aplicação.

% # Domínio de Aplicação21.6% 11 Bibliotecas/Repositórios13.7% 7 Colecções11.8% 6 Multi-Domínio11.8% 6 E-Government7.8% 4 Objectos de Aprendizagem5.9% 3 Audio/Vídeo/Multimédia

5.9% 3 Descrição ou/e relações de/entre entre Pes-soas, Comunidades ou Organizações

3.9% 2 Património Cultural3.9% 2 Imagens3.9% 2 Comunicação Científica, Editores2.0% 1 Agricultura2.0% 1 Comércio Electrónico2.0% 1 Ciência5.9% 3 Outros



Funcionais, Modelo de Domínio e Description Set Profile (DSP)Verificamos que quatro anos após a definição do Enquadramento de Singapura, dos 74 PA

seleccionados, somente 5 (6.7%) respeitam este Enquadramento - portanto somente 5 são DCAP,eles são: (i) Dryad; (ii) IAP: Images Application Profile (developed from SWAP); (iii) SWAP:The Scholary Works Application Profile; (iv) TBMAP: Time-based media application profile; (v)VMAP: Variazioni Musical Dublin Core Application Profile. Este facto revela que a comunidadeinternacional de metadados ainda não aderiu ao Enquadramento de Singapura. Contudo, érelevante que há um conjunto de PA que já desenvolveram alguns pontos do Enquadramento(estão assim a fazer o caminho para atingir o Enquadramento de Singapura). Como exemplo, oPA ANZ LOM definiu os Requisitos Funcionais e o Modelo de Domínio mas não o DSP, o PACanCORE desenvolveu Requisitos Funcionais mas não defeniu o Modelo de Domínio nem o DSP.

6.3.1.3.8 Outros resultadosDe todo o processo de análise efectuado verificámos que a comunidade de metadados não segue

toda ela a mesma terminologia para definir o conceito de PA. Encontrámos vários expressõespara se referir a um PA:

• Metadata Vocabulary• Metadata Core• Metadata Standard (e.g.: e-GMS - e-Government Metadata Standard)• Schema Vocabulary (e.g.: IOAP - On Line Journal)• Semantic Elements (e.g.: ESE - Europeana Semantic Elements)• Metadata Schema (e.g.: ADMS - Asset Description Metadata Schema)• Web Metadata Standard (e.g.: OWMS - Overheid.nl Web Metadata Standaard)Parece portanto haver alhuma dificuldade por parte da parte das pessoas que desenvolvem

PA no sentido de aderir à terminologia da DCMI, entidade que é uma das mais relevantes nacomunidade de metadados.

6.3.1.4 Limitações do estudo

Este estudo foi realizado entre Março de 2012 e Janeiro 2013. Propusemo-nos fazer um estudo queincluísse todos os PA da comunidade mundial. Sabemos que essa tarefa é uma tarefa complexa eporventura impossível de ser concretizada na sua totalidade. Listamos três limitações:

• A primeira é o facto de não termos conhecimento de todas os idiomas do mundo, peloque os artigos e informação existente fora dos idiomas de nosso conhecimento60 não foramalcançados. Ainda encontramos um PA em norueguês. Mas foi difícil entender o documento,apesar da ajuda da ferramenta da Google de tradução61.

• A segunda é o facto de alguns PA já não estarem a ser utilizados, pelo que já nãoexiste sítio Web disponível com informação, nem pessoas de contacto. Alguns PA aindaforam encontrados em artigos científicos, com bastante informação. Foi impossível obter

60Que são: espanhol, francês, holandês, inglês, italiano, português.61http://translate.google.com - acedido em 20 de Abril de 2012



informação sobre os PA que não foram publicados em artigos científicos, agora com os sítiosWeb em baixo. Exemplos são: The curriculum on-line; Learning and Teaching Scotlandapplication Profile; SingCORE ; UFI ; são PA referidos em artigos científicos - Godby (2004),de La Passière and Jarraud (2009), Manouselis et al. (2004); .

• A terceira limitação tem a ver com a dispersão de nomenclatura à volta do termo PA, essefacto dificultou muito as pesquisas.

Para terminar é importante referir as novas formas que aparecem de descrição de domíniosde conhecimento: o desenvolvimento de grandes ontologias. Foram encontradas ontologias muitointeressantes (exemplo são Breslin et al. (2005), Bojars et al. (2008)) mas que não estão noâmbito do nosso estudo. “Uma ontologia é um outro conceito que define um modelo do mundo quese quer definir, declarando quais as classes de coisas existentes nesse mundo, as suas propriedadese relacionamentos” Baker and Coyle (2013). Por outro lado, “o Enquadramento de Singapura,juntamente com o DSP Nilsson (2008), ambos baseados no Modelo Abstracto da DCMI Powellet al. (2007), descrevem um método para espressar padrões de metadados em modelos quesão independentes de plataformas” Baker and Coyle (2013). Neste contexto, os PA descrevem,portanto, as estruturas e o conteúdo dos dados.

6.3.1.5 Conclusão

A comunidade mundial de ESS possui SIW onde reúne a informação das organizações quepertencem às suas redes locais, regionais e nacionais. Esta comunidade deseja que estes sistemasse tornem interoperáveis de forma a serem uma grande rede mundial, e a estarem disponíveispara a troca da sua informação com entidades exteriores à sua comunidade. Após um estudosobre a ESS e seus SIW concluimos que eles não são de todo interoperáveis.

Esta interoperabilidade pode ser efectuada no âmbito do paradigma da WS, onde o alcance deinteroperabilidade de uma determinada implementação atinge o seu mais alto nível quando possuium DCAP. No entanto, após o estudo dos PA da comunidade de metadados concluimos que nãoexiste nenhum PA nem nenhum esquema de metadados em particular que sirva as necessidadesde descrição de recursos dos SIW da ESS. De facto, a ESS é uma comunidade muito específicae bem distinta da economia de mercado. A grande distinção entre estas comunidades é que asegunda tem o comércio como grande objectivo, a primeira é também relação. Esta dimensãorelação tem um papel muito importante na ESS. No contexto da transacção comercial a ESSnão se esgota no mero comércio. A possibilidade de descrever recursos que definem outras coisasque não somente a transacção comercial dos seus bens e serviços é essencial.

A ESS necessita de um DCAP para atingir o objectivo de interoperabilidade semântica quese propôs alcançar nos seus SIW.

6.3.2 Modelo de Domínio

A Figura 6.9 apresenta o modelo de domínio do DCAP-ESS. Este modelo identifica cincoentidades: a SSE Initiative, a Network, o Product or Service, a Location of Sale, a Sale-Option, oCost e o Cost-Composition.



Figura 6.9: Modelo de Domínio do Dublin Core Application Profile - Economia Social e Solidária

6.4 Desenvolver o Description Set Profile

A Secção 5.5 define que esta actividade composta desenvolve as actividades apresentadas naFigura 6.10 (c.f. Figura 6.11 e 6.12 para ver os diagrama de actividades nível 1). No final deveráproduzir os seguintes artefactos:

• Modelo de Dados Detalhado (Ver Secção 6.4.1);• Alinhamento de Vocabulários (ver Secção 6.4.2);• Matriz de Restrições (ver Secção 6.4.3);• Critérios de Adequação;• Teste de Adequação;• Teste em Laboratório;• Questionário.

A actividade composta “Desenvolver o DSP” terminará com a produção do deliverable DSP(c.f. Secção 6.4.4).

As actividades de desenvolvimento dos artefactos “Critérios de adequação”, “Teste de Ade-quação”, “Teste de Laboratório” e “Questionário” estão ainda a decorrer no momento de escritadesta Tese. Estas actividades deverão ocupar ainda um tempo considerável não compatível como tempo de um projecto de doutoramento, pelo que serão desenvolvidas em trabalho futuro.62.

O grupo de trabalho decidiu que, a curto prazo, a actividade de ”Validação em Produção“não será realizada.

62Para uma actualização da informação consultar Wiki do projecto: http://purl.org/essglobal/wiki




Figura 6.10: Diagrama de contexto da Etapa de Singapura: Desenvolver o Description Set Profile.

Figura 6.11: Diagrama de actividades - nível 1 da actividade composta: Desenvolver o Pré-Des-cription Set Profile.

6.4.1 Modelo de Dados Detalhado

O Modelo de Dados Detalhado foi desenvolvido com a técnica ORM. A esta técnica foramacrescentados dois símbolos para representar o multi-língua (símbolo “ML”) e a possibilidade dedescrever o atributo com um vocabulário controlado da WS (símbolo “SW”). Este modelo, porser de difícil leitura na sua totalidade, é apresentado por partes.

A Figura 6.13 apresenta em detalhe a entidade SSE Initiative, que tem como descrição:

“An organization, practice, network, or other initiative that is recognized as belonging



Figura 6.12: Diagrama de actividades - nível 1 da actividade composta: Realizar a Validação emLaboratório.

within the social solidarity economy.”

A Figura 6.14 apresenta em detalhe a entidade Network, que tem como descrição:

“A network of individuals and/or organizations that participate in the SSE.”

A Figura 6.15 apresenta em detalhe a entidade Product-Service, que tem como descrição:

“The good offered by an SSE initiative. It may be material goods or provision ofservices.”

A Figura 6.16 apresenta em detalhe a entidade Cost, que tem como descrição:

“The cost for a particular product or service produced by an SSE initiative or network,including all costs. The price will be this final cost added to delivery costs and salesmargin as can be seen in the Sale Option class.”

A Figura 6.17 apresenta em detalhe a entidade Sale-Option, que tem como descrição:

“A Product sold at a certain price, in a certain Location.”

A Figura 6.18 apresenta em detalhe a entidade Location of Sale, que tem como descrição:

“Place where the goods or services of an SSE initiative are provided. It can be selfowned shops, but also partner places where the products or services are availableamong those from other initiatives.”

A Figura 6.19 apresenta em detalhe as entidades Labour, Input e Other Costs, compondoassim o preço transparente de um produto ou serviço - entidade Cost Composition.

Labour tem a descrição:

“Work done for specific tasks related to the provision of goods or services offeredby the SSE initiative. Generally it can be human, animal or machine labour, but inESSglobal it’s human labour only.”



Figura 6.13: Entidade SSE-Initiative - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária

Input tem a descrição:

“A product, service, or activity that goes into making the final product or service.”

Other Costs tem a descrição:

“Other costs which impact on the final price of a product or service provided by anSSE initiative, other than input or labour.”

Cost Composition tem a descrição:

“A breakdown of all inputs (as taxes and raw materials) and labour costs that makeup the product or service’s final cost. An open cost is a pre-requisite for solidarityfair trade systems. ”



Figura 6.14: Entidade Network - Modelo de Dados do Dublin Core Application Profile - EconomiaSocial e Solidária.

Figura 6.15: Entidade Product-Service - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária.



Figura 6.16: Entidade Cost - Modelo de Dados do Dublin Core Application Profile - EconomiaSocial e Solidária.

Figura 6.17: Entidade Sale Option - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária.



Figura 6.18: Entidade Location of Sale - Modelo de Dados do Dublin Core Application Profile -Economia Social e Solidária.



Figura 6.19: A Entidade Cost Composition decomposta em Labour, Input e Other Costs - Modelode Dados do Dublin Core Application Profile - Economia Social e Solidária.



6.4.2 Alinhamento de Vocabulários

Os esquemas de metadados, os esquemas de codificação de vocabulário VES e esquemas decoficação de sintaxe SES seleccionados do Estado da Arte técnico do Environmental Scanencontram-se na Tabela 6.17.

Tabela 6.17: Alinhamento de Vocabulários Dublin Core Application Profile - Economia Social eSolidária.

Esquema de metadados URIDCMI Terms http://www.purl.org/dcterms/The friend of a friend http://xmlns.com/foaf/0.1/Good Relations http://purl.org/goodrelations/v1#VCARD http://www.w3.org/2006/vcard/ns/Organisation Ontology http://www.w3.org/ns/org#Schema.org http://schema.org/

SES URIISO 3166 http://purl.org/dc/terms/ISO3166

VES URITGN http://purl.org/dc/terms/TGN

6.4.3 Matriz de Restrições

A Figura 6.20 apresenta a matriz de restrições.A Figura 6.21 apresenta o diagrama UML de classes do DCAP-ESS. Aí podemos ver:• Cada classe definida com a sua propriedade de classe (e.g. A classe SSEInitiative define-se

com essglobal:SSEInitiative);• As propriedades de cada classe, também chamadas de Data Type properties63 (e.g. A classeSSEInitiative define a propriedade Name com o termo gr:name);

• As relações entre as classes, também chamadas de Object properties64 (e.g. a relaçãoentre as classes SSEInitiative e ProductOrService é definida através da propriedade essglo-bal:hasProductOrService).

Veremos na codificação RDF/XML que as Data Type properties de cada classe são definidascom um domínio do tipo classe e um contra-domínio do tipo que não é uma classe (e.g. literal).As Object properties são definidas com um domínio e um contra-domínio do tipo classe.

A Figura 6.22 apresenta a tabela que resume a informação relativa ao vocabulário ESSGlobal.Ela contém as classes e respectivas propriedades.

63Em OWL owl:DatatypeProperty - c.f http://www.w3.org/TR/owl-ref/. Acedido em 17 de Abril 2014.64Em OWL owl:ObjectProperty - c.f http://www.w3.org/TR/owl-ref/. Acedido em 17 de Abril 2014.


http://www.w3.org/TR/owl-ref/

http://www.w3.org/TR/owl-ref/


Constraints Matrix: DCAP SSE

Definition of Namespaces used

Title Full Namespace URI Prefix

DCMI Terms http://purl.org/dc/terms/ dcterms

The friend of a friend http://xmlns.com/foaf/0.1/ foaf

Good Relations http://purl.org/goodrelations/v1# gr

VCARD http://www.w3.org/2006/vcard/ns/ v

Schema.org http://schema.org schema

Social and Solidarity Economy vocabulary http://purl.org/essglobal/vocab/v1.0/ essglobal

Definition of Description Templates

Description Template: SSE initiative Property: essglobal:SSEInitiative Usage:

Label Property Range SES URI Value URI VES URI Min Max Type Usage

Name gr:name literal YES no n/a n/a n/a 1 1 n/a The name of the SSE initiative in its original language

Description dcterms:description literal YES no n/a n/a n/a 0 1 n/a A description of the SSE initiative

Objective essglobal:objective literal YES no n/a n/a n/a 0 1 n/a

Mission essglobal:mission literal YES no n/a n/a n/a 0 1 n/a The initiative's vision, values, and principles.

Type dc:type literal YES no n/a n/a n/a 0 infinity n/a

Economic-Sector essglobal:economicSector non-literal no no YES n/a 0 infinity n/a

Total of Women essglobal:totalWomen literal YES no n/a n/a n/a 0 1 n/a The number of women that work in the SSE Initiative.

Total of Men essglobal:totalMen literal YES no n/a n/a n/a 0 1 n/a The number of men that work in the SSE Initiative.

Total of Members essglobal:totalOfMembers literal YES no n/a n/a n/a 0 1 n/a The total number of members that work in the SSE Initiative.

Legal Form essglobal:legalForm non-literal no no YES n/a 0 1 n/a

URL foaf:homepage literal YES no n/a n/a n/a 0 1 n/a The initiative's homepage

Has Product or Service essglobal:hasProductOrService non-literal YES no no no YES 0 infinity n/a The good offered by the SSE initiative.

Is part of a Network dcterms:isPartOf non-literal YES no no no YES 0 infinity n/a

Description Template: Network Property: essglobal:Network Usage: A network of individuals and/or organizations that participate in the SSE.


Name gr:name literal YES no n/a n/a n/a 1 1 n/a Name of the network

Description dcterms:description literal YES no n/a n/a n/a 0 1 n/a A description of the network

Objective essglobal:objective literal YES no n/a n/a n/a 0 1 n/a

Legal Form essglobal:legalForm non-literal no no YES n/a 0 1 n/a ESSGlobal has established a VES for this property.

Mission essglobal:mission literal YES no n/a n/a n/a 0 1 n/a The Network's vision, values, and principles.

URL foaf:homepage literal YES no n/a n/a n/a 0 1 n/a The Network's homepage

Is made of SSE Initiatives dcterms:hasPart non-literal YES no no no YES 1 infinity n/a The SSE Initiative which the Network is made of

Has Product or Service essglobal:hasProductOrService non-literal YES no no no YES 0 infinity n/a The good offered by the Network.

An organization, practice, network, or other initiative that is recognized as belonging within the social solidarity economy.

Value String

Related description

Actionable and measurable steps the initiative is taking to carry out its mission.

http://purl.org/essglobal/standard/activities

The economic sector of the SSE Initiative. ESSGlobal has established a VES form this term.

http://purl.org/essglobal/standard/legal-form

A network of individuals and/or organizations that the SSE Initiative belongs to.

Value String

Related description

Actionable and measurable steps the initiative is taking to carry out its mission.

http://purl.org/essglobal/standard/legal-form

Figura 6.20: Matriz de restrições do Dublin Core Application Profile - Economia Social e Solidária.



Description Template: Product-or-Service Property: essglobal:ProductOrService Usage: The good offered by an SSE initiative or Network. It may be material goods or provision of services.


Name gr:name literal YES no n/a no n/a 1 1 n/a Name of the product or service provided by SSE initiative.

Description dcterms:description literal YES no n/a no n/a 0 1 n/a Description of the product or service provided by the SSE initiative.

Category gr:category literal YES no YES n/a 0 infinity n/a

Qualifier essglobal:qualifier non-literal YES no YES n/a 0 infinity n/a

Image foaf:depicts non-literal no no YES no n/a 0 1 n/a Image of product or service.

Unit gr:hasUnitOfMeasurement literal YES no n/a n/a n/a 0 1 n/a

Has a Sale Option essglobal:hasSaleOption non-literal YES no no no YES 0 infinity n/a

Has Cost essglobal:hasCost non-literal YES no no no YES 0 1 n/a

Description Template: Cost Property: essglobal:Cost


Value gr:hasCurrencyValue literal YES no no no n/a 1 1 n/a

Currency gr:hasCurrency non-literal no To identify n/a n/a n/a 1 1 n/a Currency of the product or service's final cost.

Is Composed By essglobal:isComposedBy non-literal YES no no no YES 1 1 n/a

Description Template: Sale Option Property: essglobal:SaleOption Usage: A Product sold at a certain price, under specific properties, in a certain Location.


isavailable essglobal:isAvailable Non-literal no http://schema.org/Boolean no n/a n/a 1 1

Sales Margin Percentage essglobal:salesMarginPercentage literal YES no no no n/a 1 1 n/a

Sales Margin Value essglobal:salesMarginValue literal YES no no no n/a 1 1 n/a

Delivery Cost gr:hasCurrencyValue literal YES no no no n/a 1 1 n/a

Price gr:hasCurrencyValue literal YES no no no n/a 1 1 n/a

essglobal:isAavailableAt non-literal YES no no no YES 1 1 n/a

Value String

Related description

http://purl.org/essglobal/standard/products-services

Products and services should be categorized according to the United Nations Standard Products and Services Code (UNSPSC). This code has been developed by the United Nations Development Programme (UNDP) to classify all products and services. The code has four levels (from most general to most specific): Segment, Family, Class, Commodity. ESSGlobal uses only the first two levels (Segment and Family). The UNSPSC can be found at: www.unspsc.org/ . ESSGlobal has established a VES for this term.

http://purl.org/essglobal/standard/qualifiers

A qualification according to the type of product. Ex: ecological or sustainable environmentally, gender issues, etc. ESSGlobal has established a VES with a set of qualifiers to differentiate SSE products and services.

Unit of measurement for assessglobaling quantity (e.g., bushel, gallon, pounds). A list of scientific units can be found at: http://physics.nist.gov/cuu/Units/units.html|http://physics.nist.gov/cuu/Units/units.html|http://physics.nist.gov/cuu/Units/units.html A Product sold at a certain price, under specific properties, in a certain Location.

The cost for a particular product or service produced by an SSE initiative or network.

Usage:The cost for a particular product or service produced by an SSE initiative or network, including all costs. The price will be this cost added to delivery costs and sales margin as can be seen in the sale-option class.

Value String

Related description

The final Cost of the product or service. The sum up of all the components: Input, Labour and Other Costs.

A breakdown of all inputs (as taxes and raw materials) and labour costs that make up the product or service's final cost. An open cost is a pre-requisite for solidarity fair trade systems.

Value String

Related description

rdf:type boolean

If the Sale Option (the product/service at a certain price, under specific properties, in a specific Sale Location) is available.

Margin (on sales) is the difference between selling price and cost. This difference is typically expressed either as a percentage of selling price or on a per-unit basis. This attribute is the percentage sales margin.

Margin (on sales) is the difference between selling price and cost. This difference is typically expressed either as a percentage of selling price or on a per-unit basis. The present attribute is an absolute value for sales margin on each unit of the product or service offered in the location.

Additional cost which includes the delivery services costs, like posting, transport, etc.

The price for the consumer, which adds the sales margin and delivery costs to the final cost of “cost-composition” in the following manner: If the location has a sales-margin-percentage, the price will be cost-composition.final-cost*(1+sales-margin-percentage) + delivery-costs. If the location has a sales-margin-value, the final price will be cost-composition.final-cost + sales-margin-value + delivery-costs .

Is available at a Location of Sale

A sale option is connected to a place where the good or service is provided.

Figura 6.20: Matriz de restrições do Dublin Core Application Profile - Economia Social e Solidária (continua).



Description Template: Location-of-Sale Property: essglobal:LocationOfSale


Name dcterms:title literal YES no no no n/a 1 1 n/a Name of sale location (e.g., Philadelphia Branch, Headquarters)

Addressglobal v:street-addressglobal literal YES no no no n/a 0 1 n/a Street name of sale location.

Zip-Code v:postal-code literal YES no no no n/a 0 1 n/a Zip code of location of sale.

State essglobal:state literal YES no no no n/a 0 1 n/a State of location of sale.

City v:locality non-literal YES no no http://purl.org/dc/terms/TGN n/a 0 1 n/a City code of location of sale.

Country v:country-name non-literal no http://purl.org/dc/terms/ISO3166 no n/a n/a 0 1 n/a Country of location of sale.

isMain essglobal:isMain Non-literal no http://schema.org/Boolean no n/a n/a 0 1 If the Location of Sale is the headquarter of the SSE initiative.

isSSEInitiative essglobal:isSSE Non-literal no http://schema.org/Boolean no n/a n/a 0 1 If the Location of Sale is a place belonging to the SSE.

Mobile-Phone schema:telephone literal YES no no no n/a 0 1 n/a Mobile number of location of sale.

Phone schema:telephone literal YES no no no n/a 0 1 n/a Phone number of location of sale.

Email foaf:mbox non-literal no no no no n/a 0 1 mailto:URI Email addressglobal of location of sale.

Fax schema:faxnumber literal YES no no no n/a 0 1 n/a Fax number of location of sale.

Delivery Range Distance essglobal:deliveryRangeDistance literal YES no no no n/a 0 1 n/a

gr:eligibleRegions non-literal no http://purl.org/dc/terms/ISO3166 no n/a n/a 0 infinity n/a

Longitude v:longitude literal YES no no no n/a 0 1 n/a Longitude coordinates of location of sale.

Latitude v:latitude literal YES no no no n/a 0 1 n/a Latitude coordinates of location of sale.

Description Template: Cost-Composition Property: essglobal:CostComposition


Has Input essglobal:hasInputCost non-literal YES no no no YES 0 infinity n/a

Has Labour essglobal:hasLabourCost non-literal YES no no no YES 0 infinity n/a

Has Other Costs essglobal:hasOtherCosts non-literal YES no no no YES 0 infinity n/a

Description Template: Input Property: essglobal:Input A product, service, or activity that goes into making the final product or service.


Description dcterms:description literal YES no n/a n/a n/a 1 1 n/a A description of the input.

literal YES no n/a n/a n/a 1 1 n/a

Cost per Unit essglobal:costPerUnit literal YES no n/a n/a n/a 1 1 n/a

Unit essglobal:unit literal YES no YES n/a* no 1 1 n/a

Has Impact on Cost essglobal:hasImpactOnCost Non-literal no http://schema.org/Boolean no n/a n/a 1 1

Qualifier essglobal:qualifier non-literal YES no YES n/a 0 infinity n/a

Usage:Place where the goods or services of an SSE initiative are provided. It can be self owned shops, but also partner places where the products or services are available among those from other initiatives.

Value String

Related description

rdf:type booleanrdf:type boolean

Delivery range of product or service, in kilometers or miles. If this term is defined, the term “Delivery-Range-Geographic-Area” has to be left empty.

Delivery Range Geographic Area

Delivery range of product or service, by geographic area. It is a list of cities or other geographic regions inside a country or internationally. If this term is defined, the term “Delivery-Range-Distance” has to be left empty.

Usage:A breakdown of all inputs (as taxes and raw materials) and labour costs that make up the product or service's final cost. An open cost is a pre-requisite for solidarity fair trade systems.

Value String

Related description

Defines the cost related to a product, service, or activity that goes into making the final product or service.

Defines the cost of the work done for specific tasks related to the provision of goods or services offered by the SSE initiative. Generally it can be human, animal or machine labour, but in ESSglobal it's human labour only.

Defines other costs which impact on the final cost of a product or service provided by an SSE initiative, other than input or labour, like taxes, deprecation of machinery, funds, etc.

Usage:

Value String

Related description

Quantity per ProductOrService Unit

essglobal:quantityPerProductOrServiceUnit

The quantity of the input that goes into making the final product or service.

The currency of the price or cost per unit of a good or service (be it input or the final product/service)The unit that a product or service is measured in, in the Universal Unit System (e.g., kilograms, hours)

rdf:type boolean

Does the input contribute to the monetary price of the final product: YES or NO? Whereas many (perhaps most) inputs do contribute to the monetary price of the final product or service, some don't. For example, volunteer labor may contribute greatly to production without adding to the monetary cost of production.

http://purl.org/essglobal/standard/qualifiers

A qualification according to the type of product. Ex: ecological or sustainable environmentally, gender issues, etc. ESSGlobal has established a VES with a set of qualifiers to differentiate SSE products and services.

Figura 6.20: Matriz de restrições do Dublin Core Application Profile - Economia Social e Solidária (continua).



Category gr:category literal YES no YES n/a 0 infinity n/a

Description Template: Labour Property: essglobal:Labour


Type essglobal:typeOfLabour literal YES no YES no 0 1 n/a

Description dcterms:description literal YES no n/a no no 1 1 n/a A description of the Labour

Contribution to the Cost gr:hasCurrencyValue literal YES no n/a n/a no 1 1 n/a

Description Template: Other-Costs Property: essglobal:OtherCosts


Description dcterms:description literal YES no n/a no no 1 1 n/a A description of other costs.

Has Impact on Cost essglobal:hasImpactOnCost Non-literal no http://schema.org/Boolean no n/a n/a 1 1

Contribution to the Cost gr:hasCurrencyValue literal YES no n/a n/a no 1 1 n/a

http://purl.org/essglobal/standard/products-services

Products and services should be categorized according to the United Nations Standard Products and Services Code (UNSPSC). This code has been developed by the United Nations Development Programme (UNDP) to classify all products and services. The code has four levels (from most general to most specific): Segment, Family, Class, Commodity. ESSGlobal uses only the first two levels (Segment and Family). The UNSPSC can be found at: www.unspsc.org/ . ESSGlobal has established a VES for this term.

Usage:Work done for specific tasks related to the provision of goods or services offered by the SSE initiative. Generally it can be human, animal or machine labour, but in ESSglobal it's human labour only.

Value String

Related description

http://purl.org/essglobal/standard/type-of-labour

The human labour dedicated for providing goods or services can be of different types, depending on the established labour relations. For example, it might be associative (i.e., the worker is one of the collective owners of the SSE initiative), but it might also be subordinated work (an employee of the SSE initiative), volunteer work or externally hired work (like a freelancer or a partner initiative).

In the final product of service provided by an SSE initiative, what is the contribution of labour? This is a monetary value per unit of a final product or service.

Usage:Other costs which impact on the final cost of a product or service provided by an SSE initiative, other than input or labour, like taxes, deprecation of machinery, funds, etc. The delivery costs are not included in these costs: they are included in the sale-options class.

Value String

Related description

rdf:type boolean


In the final product of service provided by an SSE initiative, what is the contribution of other costs? This is a monetary value per unit of a final product or service.

Figura 6.20: Matriz de restrições do Dublin Core Application Profile - Economia Social e Solidária.



gr: name

dcterms:description

gr: category

essglobal:qualifier

foaf:depicts

gr:hasUnitOfMeasurement

essglobal:ProductOrService

gr: name

dcterms:description

essglobal:objective

dc:type

essglobal:economicSector

essglobal:totalWomen

essglobal:totalMen

essglobal:totalOfMembers

essglobal:legalForm

essglobal:mission

foaf:homepage

essglobal:SSEInitiative

gr: name

dcterms:description

essglobal:objective

essglobal:legalForm

essglobal:mission

foaf:homepage

essglobal:Network

dcte

rms: is

Pa

rtof

dcte

rms: h

asP

art

essglobal:hasProductOrService

essglobal:hasSaleOption

dcterms:title

v:street-addressglobal

v:postal-code

v:locality

essglobal:state

v:country-name

essglobal:isMain

essglobal:isSSE

schema:telephone

schema:telephone

foaf:mbox

schema:faxnumber

essglobal:deliveryRangeDistance

gr:eligibleRegions

v: logitude

v:latitude

essglobal:LocationOfSale

essglobal:isAvailableAt

essglobal:hasInputCost

essg

lob

al: h

asL

ab

ou

rCo

st

essg

lob

al:h

asP

rod

uctO

rSe

rvic

e

essglobal:CostComposition

essglobal:typeOfLabour

dcterms:description

gr:hasCurrencyValue

essglobal:Labour

dcterms:description

essglobal:quantityPerProductorServiceUnit

essglobal:CostPerUnit

essglobal:unit

essglobal:hasImpactOnCost

essglobal:qualifier

gr:category

gr:hasCurrencyValue

gr:hasCurrency

dcterms:description

essglobal:hasImpactOnCost

gr:hasCurrencyValue

essglobal:Cost

essglobal:isComposedBy

essglobal:OtherCosts

essglobal:isAvaliable

essglobal:salesMarginPercentage

essglobal:salesMarginValue

gr: hasCurrencyValue

gr: hasCurrencyValue

essglobal:SaleOption

essglobal:Input

dcterms:http:/purl.org/dc/terms/

essglobal: http://purl.org/essglobal/vocab/v1.0/

foaf:http://xmlns.xom/foaf/0.1/

gr:http://purl.org/goodrelations/v1#

schema: http://schema.org

v:http://www.w3.org/2006/vcard/ns/

NAMESPACES

essglobal:hasOtherCosts

essg

lob

al:h

asC

ost

Figura 6.21: Diagrama UML de classes do Dublin Core Application Profile - Economia Social e Solidária.



ESSGlobal Vocabulary V1.0

Title Prefix Full Namespace URI

Social Solidarity Economy vocabulary essglobal http://purl.org/essglobal/vocab/v1.0/

SSE initiative class essglobal:SSEInitiative An organization, practice, network, or other initiative that is recognized as belonging within the social solidarity economy.

Objective essglobal:objective Actionable and measurable steps the initiative is taking to carry out its mission.

Mission essglobal:mission The initiative's vision, values, and principles.

Economic-Sector essglobal:economicSector A categorization of the type of activities carried on by SSE initiatives, depending of its nature, raw materials and methodology.

Legal Form essglobal:legalForm

Total of Women essglobalglobal:totalWomen The number of women that are members of the SSE Initiative.

Total of Men essglobal:totalMen The number of men that are members of the SSE Initiative.

Total of Members essglobal:totalOfMembers The total number of members of the SSE Initiative.

Has Product or Service essglobal:hasProductOrService The good offered by an SSE initiative or a Network.

Network class A network of individuals and/or organizations that participate in the SSE.

Objective essglobal:objective Actionable and measurable steps the initiative is taking to carry out its mission.

Mission essglobal:mission The initiative's vision, values, and principles.

Legal Form essglobal:legalForm

Has Product or Service essglobal:hasProductOrService The good offered by an SSE initiative or a Network.

ProductOrService class essglobal:ProductorService The good offered by an SSE initiative. It may be material goods or provision of services.

Qualifier essglobal:qualifier

Has a Sale Option essglobal:hasSaleOption A Product sold at a certain price, under specific properties, in a certain Location.

Has Cost essglobal:hasCost The cost for a particular product or service produced by an SSE initiative or network.

Cost class essglobal:Cost

Is Composed By essglobal:isComposedBy A breakdown of all inputs (as taxes and raw materials) and labour costs that make up the product or service's final cost. An open cost is a pre-requisite for solidarity fair trade systems.

Sale Option class essglobal:SaleOption A Product sold at a certain price, under specific properties, in a certain Location.

isavailable essglobal:isAvailable If the Sale Option (the product/service at a certain price, under specific properties, in a specific Sale Location) is available.

Sales Margin Percentage essglobal:salesMarginPercentage

Sales Margin Value essglobal:salesMarginValue

Is available at a Location of Sale essglobal:isAvailableAt A sale option is connected to a place where the good or service is provided.

Location-of-Sale class essglobal:LocationOfSale

State essglobal:state State of location of sale.

isMain essglobal:isMain If the Location of Sale is the headquarter of the SSE initiative.

isSSEInitiative essglobal:isSSE If the Location of Sale is a place belonging to the SSE.

Delivery Range Distance essglobal:deliveryRangeDistance Delivery range of product or service, in kilometers or miles. If this term is defined, the term “Delivery-Range-Geographic-Area” has to be left empty.

Cost-Composition class essglobal:CostComposition A breakdown of all inputs (as taxes and raw materials) and labour costs that make up the product or service's final cost. An open cost is a pre-requisite for solidarity fair trade systems.

Has Input essglobal:hasInputCost Defines the cost related to a product, service, or activity that goes into making the final product or service.

Has Labour essglobal:hasLabourCost

Has Other Costs essglobal:hasOtherCosts Defines other costs which impact on the final cost of a product or service provided by an SSE initiative, other than input or labour, like taxes, deprecation of machinery, funds, etc.

Input class essglobal:Input

essglobal:Network

Aspect that differentiates the product or service of an SSE initiative which is related to the form of production, the actors involved, the use of only organic materials, etc. Examples are “organic”, “permacultural”, “made with recycled raw materials”, “indigenous”, “made by women”, etc.

The final cost for a particular product or service produced by an SSE initiative or network, including all costs. The price will be this final cost added to delivery costs and sales margin as can be seen in the sale-option class.

Margin (on sales) is the difference between selling price and cost. This difference is typically expressed either as a percentage of selling price or on a per-unit basis. This attribute is the percentage sales margin. If this one is used, the Sales Margin (value) property should not be used.

Margin (on sales) is the difference between selling price and cost. This difference is typically expressed either as a percentage of selling price or on a per-unit basis. The present attribute is an absolute value for sales margin on each unit of the product or service offered in the location. If this one is used, the Sales Margin (percentage) property should not be used.

Place where the goods or services of an SSE initiative are provided. It can be self owned shops, but also partner places where the products or services are available among those from other initiatives.

Defines the cost of the work done for specific tasks related to the provision of goods or services offered by the SSE initiative. Generally it can be human, animal or machine labour, but in ESSglobal it's human labour only.

A product (like raw-materials), service, tax or activity that goes into making the final product or service. For example, a cake can have the wheat and the package as input, but also the taxes and other costs involved in its production.

Figura 6.22: Tabela resumo do novo vocabulário criado: ESSGlobal V1.0.



Quantity-per-ProductOrService-Unit The quantity of the input that goes into providing one unit of the final product or service.

Cost per Unit sssglobal:inputCostPerUnit The cost per unit of input.

Unit essglobal:unit The unit that a product or service is measured in, in the Universal Unit System (e.g., kilograms, hours)

Has Impact on Cost essglobal:hasImpactOnCost

Labour class essglobal:Labour

Type essglobal:typeOfLabour

Other-Costs class essglobal:OtherCosts

Has Impact on Cost essglobal:hasImpactOnCost

essglobal:quantityPerProductOrServiceUnit

Does the input contributes to the monetary price of the final product: YES or NO? Whereas many (perhaps most) inputs do contribute to the monetary price of the final product or service, some don't. For example, volunteer labour may contribute greatly to production without adding to the monetary cost of production.

Work done for specific tasks related to the provision of goods or services offered by the SSE initiative. Generally it can be human, animal or machine labour, but in ESSglobal it's human labour only.

The human labour dedicated for providing goods or services can be of different types, depending on the established labour relations. For example, it might be associative (i.e., the worker is one of the collective owners of the SSE initiative), but it might also be subordinated work (an employee of the SSE initiative), volunteer work or externally hired work (like a freelancer or a partner initiative).

Other costs which impact on the final cost of a product or service provided by an SSE initiative, other than input or labour, like taxes, deprecation of machinery, funds, etc. The delivery costs are not included in these costs: they are included in the sale-options class.


Fig 6.22: Tabela resumo do novo vocabulário criado: ESSGlobal V1.0.



De seguida apresentamos o código RDF/XML relativo à criação das classes do vocabulárioESSGlobal. Algumas das classes são definidas como sendo uma sub-classe (rdfs:subClassOf ) deoutra classe definida na comunidade de metadados, de forma a realizar um crosswalk65 (e.g aclasse SSE Initiative é uma sub-classe da classe Organization Unit da ontologia “org” (Namespace:http://www.w3.org/ns/org#). O resumo dos crosswalks das classes encontra-se na Tabela 6.18.A Figura 6.23 é o grafo66 gerado a partir da codificação RDF/XML com as classes e suas relações(object properties).

• Classe SSEIntiative:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ SSEIn i t i a t i v e ">2 <r d f s : l a b e l xml:lang=" en ">SSE I n i t i a t i v e</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">An organ i za t i on , p rac t i c e , network , or

other i n i t i a t i v e that i s r e cogn i z ed as be long ing with in the s o c i a ls o l i d a r i t y economy .</ dc t e rms : d e s c r i p t i on>

4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 <rd f s : subC la s sO f r d f : r e s o u r c e=" h t tp : //www.w3 . org /ns/ org#Organizat ionUnit " />6 </ r d f s : C l a s s>

• Classe Network:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ Network ">2 <r d f s : l a b e l xml:lang=" en ">Network</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">A network o f i n d i v i d u a l s and/ or

o r gan i z a t i on s that p a r t i c i p a t e in the SSE . </ dc t e rms : d e s c r i p t i on>4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 <rd f s : subC la s sO f r d f : r e s o u r c e=" h t tp : //www.w3 . org /ns/ org#

Organ izat ionColaborat ion " />6 </ r d f s : C l a s s>

• Classe ProductOrService:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ ProductOrService ">

2 <r d f s : l a b e l xml:lang=" en ">Product or Se rv i c e</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">The good o f f e r e d by an SSE i n i t i a t i v e .

I t may be mate r i a l goods or p rov i s i on o f s e r v i c e s . </dc t e rms : d e s c r i p t i on>

4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 <rd f s : subC la s sO f r d f : r e s o u r c e=" h t tp : // pur l . org / good r e l a t i on s /v1#

ProductOrService " />6 </ r d f s : C l a s s>

65Crosswalks são usados para comparar termos de um esquema em relação a outro esquema de metadados,possibilitando mapeamentos, potenciando interoperabilidade. É esta possibilidade que permite a realização dorelacionamento de conjuntos de dados, que utilizam um determinado perfil de aplicação para formatar os seusdados, com outros conjuntos de dados de outras comunidades.

66Todos os grafos criados foram gerados com a ferramenta Graphvviz - http://www.graphviz.org/ - acedidoem 13 de Maio de 2014.


http://www.w3.org/ns/org#

http://www.graphviz.org/


• Classe LocationOfSale:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ Locat ionOfSale ">2 <r d f s : l a b e l xml:lang=" en ">Locat ion o f Sa l e</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">Place where the goods or s e r v i c e s o f an

SSE i n i t i a t i v e are provided . I t can be s e l f owned shops , but a l s opartner p l a c e s where the products or s e r v i c e s are a v a i l a b l e among thosefrom other i n i t i a t i v e s . </ dc t e rms : d e s c r i p t i on>

4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 <rd f s : subC la s sO f r d f : r e s o u r c e=" h t tp : // pur l . org / good r e l a t i on s /v1#Locat ion " />6 </ r d f s : C l a s s>

• Classe Cost:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ Cost ">2 <r d f s : l a b e l xml:lang=" en ">Cost</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">The co s t f o r a p a r t i c u l a r product or

s e r v i c e produced by an SSE i n i t i a t i v e or network , i n c l ud ing a l l c o s t s .The p r i c e w i l l be t h i s co s t added to d e l i v e r y c o s t s and s a l e s margin ascan be seen in the sa l e−opt ion c l a s s .</ dc t e rms : d e s c r i p t i on>

4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 </ r d f s : C l a s s>

• Classe SaleOption:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ SaleOption ">2 <r d f s : l a b e l xml:lang=" en ">Sa le Option</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">A Product so ld at a c e r t a i n pr i ce , under

s p e c i f i c p rope r t i e s , in a c e r t a i n Locat ion . </ dc t e rms : d e s c r i p t i on>4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 </ r d f s : C l a s s>

• Classe CostComposition:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ CostComposition ">2 <r d f s : l a b e l xml:lang=" en ">Cost Composition</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">A breakdown o f a l l inputs ( as taxes and

raw mate r i a l s ) and labour c o s t s that make up the product or s e r v i c e ’ sf i n a l co s t . An open co s t i s a pre−r e q u i s i t e f o r s o l i d a r i t y f a i r t radesystems . </dc t e rms :de s c r i p t i on>

4 <rd f s : i sDe f in edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f in edBy>5 </rd f s :C l a s s >

• Classe Input:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ Input ">2 <r d f s : l a b e l xml:lang=" en ">Input</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">A product , s e r v i c e , or a c t i v i t y that

goes in to making the f i n a l product or s e r v i c e . </ dc t e rms : d e s c r i p t i on>4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 <\ r d f s : C l a s s>



• Classe Labour :

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ Labour ">2 <r d f s : l a b e l xml:lang=" en ">Labour</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">Work done f o r s p e c i f i c ta sk s r e l a t e d to

the p rov i s i on o f goods or s e r v i c e s o f f e r e d by the SSE i n i t i a t i v e .Genera l ly i t can be human , animal or machine labour , but in ESSglobali t ’ s human labour only .</ dc t e rms :de s c r i p t i on>

4 <rd f s : i sDe f in edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f in edBy>5 </rd f s :C l a s s >

• Classe OtherCosts:

1 <r d f s : C l a s s rd f : abou t=" h t tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/ OtherCosts ">2 <r d f s : l a b e l xml:lang=" en ">Other Costs</ r d f s : l a b e l>3 <dc t e rms : d e s c r i p t i on xml:lang=" en ">Other c o s t s which impact on the f i n a l

co s t o f a product or s e r v i c e provided by an SSE i n i t i a t i v e , other thaninput or labour , l i k e taxes , deprecat i on o f machinery , funds , e t c . Thed e l i v e r y c o s t s are not inc luded in these c o s t s : they are inc luded inthe sa l e−opt ions c l a s s .</ dc t e rms : d e s c r i p t i on>

4 <rd f s : i sDe f i n edBy>ht tp : // pur l . org / e s s g l o b a l /vocab/v1 .0/</ rd f s : i sDe f i n edBy>5 </ r d f s : C l a s s>

Tabela 6.18: Crosswalk rdfs:subclassOf do vocabulário ESSGlobal V1.0.

ESSGlobal Crosswalk namespace Crosswalk termoSSEInitiative http://www.w3.org/ns/org# OrganizationUnitNetwork http://www.w3.org/ns/org# OrganizationColaborationProductOrService http://purl.org/goodrelations/v1# ProductOrServiceLocationOfSale http://purl.org/goodrelations/v1# Location

De seguida apresentamos o código RDFXML relativo à criação das Object Properties(owl:ObjectProperty). Algumas das propriedades são definidas como sendo equivalentes(owl::equivalentProperty) a outras propriedades existentes na comunidade de metadados, de formaa realizar um crosswalk (e.g a propriedade hasProductOrService é uma propriedade equivalente àpropriedade offers da ontologia “gr” (Namespace: http://purl.org/goodrelations/v1#). Oresumo dos crosswalks das propriedades encontra-se na Tabela 6.19.

• Propriedade hasProductOrService. Propriedade que relaciona as classes SSE Initiative ouNetwork com a classe Product or Service:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/hasProductOrService ">

2 <rd f s : l a b e l xml : lang=" en ">Has Product or Serv i ce </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">A Network or SSE I n i t i a t i v e produce

products or make av a i l a b l e s e r v i c e s .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "

/>


http://purl.org/goodrelations/v1#


5 <rd f s : domain>6 <owl : Class>7 <owl : unionOf>8 <rd f : Descr ipt ion>9 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

Network "/>10 <rd f : r e s t>11 <rd f : Descr ipt ion>12 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1

.0/ SSEIn i t i a t i v e "/>13 <rd f : r e s t rd f : r e s ou r c e=" http ://www.w3 . org /1999/02/22− rdf−

syntax−ns#n i l "/>14 </rd f : Descr ipt ion>15 </rd f : r e s t>16 </rd f : Descr ipt ion>17 </owl : unionOf>18 </owl : Class>19 </rd f s : domain>20 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

ProductOrService "/>21 <owl : equ iva l entProper ty rd f : r e s ou r c e=" http :// pur l . org / good r e l a t i on s /v1#

o f f e r s "/>22 </owl : ObjectProperty>

• Propriedade hasSaleOption. Propriedade que relaciona a classe Product or Service com aclasse Sale Option:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/hasSaleOption ">

2 <rd f s : l a b e l xml : lang=" en ">Has a Sa le Option</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">A sa l a opt ion s i connected to a p lace

where the good or s e r v i c e i s provided .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

ProductOrService "/>6 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ SaleOption "

/>7 </owl : ObjectProperty>

• Propriedade isAvailableAt. Propriedade que relaciona a classe SaleOption com a classeLocation:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/i sAva i l ab l eAt ">

2 <rd f s : l a b e l xml : lang=" en ">I s Ava i l ab l e At</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">A Product or Se rv i c e i s s o ld at a s a l e

l o c a t i o n under s p e c i f i c d e f i n i t i o n s .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ SaleOption "

/>



6 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/Locat ionOfSale " />

7 <owl : equ iva l entProper ty rd f : r e s ou r c e=" http :// pur l . org / good r e l a t i on s /v1#availableAtOrFrom "/>

8 </owl : ObjectProperty>

• Propriedade hasCost. Propriedade que relaciona a classe Product or Service com a classeCost:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ hasCost ">2 <rd f s : l a b e l xml : lang=" en ">Has Cost</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The co s t for a p a r t i c u l a r product or

s e r v i c e produced by an SSE i n i t i a t i v e or network .</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

ProductOrService "/>6 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Cost "/>7 </owl : ObjectProperty>

• Propriedade isComposedBy. Propriedade que relaciona a classe Cost com a classe CostComposition:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/isComposedBy ">

2 <rd f s : l a b e l xml : lang=" en ">I s Composed By</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">A breakdown o f a l l inputs ( as taxes and

raw mate r i a l s ) and labour c o s t s that make up the product or s e r v i c e ’ sf i n a l co s t . An open co s t i s a pre−r e q u i s i t e f o r s o l i d a r i t y f a i r t radesystems .</dcterms : d e s c r i p t i on >

4 <rd f s : i sDef inedBy rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/"/>5 <rd f s : domain rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Cost"/>6 <rd f s : range rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

CostComposition"/>7 </owl : ObjectProperty>

• Propriedade hasInputCost. Propriedade que relaciona a classe Cost Composition com aclasse Input:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/hasInputCost ">

2 <rd f s : l a b e l xml : lang=" en ">Has Input Cost</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">Def ines the co s t r e l a t e d to a product ,

s e r v i c e , or a c t i v i t y that goes in to making the f i n a l product or s e r v i c e.</dcterms : d e s c r i p t i on>

4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

CostComposition "/>6 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Input "/>7 </owl : ObjectProperty>



• Propriedade hasLabourCost. Propriedade que relaciona a classe Cost Composition com aclasse Labour :

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/hasLabourCost ">

2 <rd f s : l a b e l xml : lang=" en ">Has Labour Cost</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">Def ines the co s t o f the work done for

s p e c i f i c ta sk s r e l a t e d to the p rov i s i on o f goods or s e r v i c e s o f f e r e d bythe SSE i n i t i a t i v e . Genera l ly i t can be human , animal or machine

labour , but in ESSglobal i t ’ s human labour only .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/"/>5 <rd f s : domain rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

CostComposition"/>6 <rd f s : range rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Labour"/>7 </owl : ObjectProperty>

• Propriedade hasOtherCosts. Propriedade que relaciona a classe Cost Composition com aclasse Other Costs:

1 <owl : ObjectProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/hasOtherCosts ">

2 <rd f s : l a b e l xml : lang=" en ">Has Other Costs</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">Def ines other c o s t s which impact on the

f i n a l co s t o f a product or s e r v i c e provided by an SSE i n i t i a t i v e , otherthan input or labour , l i k e taxes , deprecat i on o f machinery , funds , e t c

.</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

CostComposition "/>6 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ OtherCosts "

/>7 </owl : ObjectProperty>

As Figuras 6.24 e 6.25 são os grafos gerados a partir da codificação RDF/XML com o detalhedas object properties referidas.

Tabela 6.19: Crosswalk owl:equivalentProperty do vocabulário ESSGlobal V1.0.

ESSGlobal Crosswalk namespace Crosswalk termohasProductOrService http://purl.org/goodrelations/v1# offersisAvailableAt http://purl.org/goodrelations/v1# availableAtOrFrom



Figura 6.23: Grafo com todas as classes do vocabulário ESSGlobal e respectivas relações (owl:ObjectProperty) entre classes.



Figura 6.24: Grafo com as propriedades (owl:ObjectProperty) “hasProductOrService”, “hasCost” “hasSaleOption” e “isComposedBy” do vocabulário ESSGlobal.

Figura 6.25: Grafo com as propriedades (owl:ObjectProperty) “isAvailableAt”, “hasInputCost” “hasLabourCost” e “hasOtherCosts” do vocabulário ESSGlobal.



Foram ainda criadas quatro classes de forma a implementar a utilização de VES (ver Ta-bela 6.20) em determinadas DataType Properties. As clases são: Activities, LegalForm, Qualifierse TypeOfLabour.

1 <rd f : De sc r ip t i on rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ A c t i v i t i e s ">2 <rd f s : l a b e l xml : lang=" en ">Ac t i v i t i e s VES</rd f s : l abe l >3 <dc : d e s c r i p t i o n xml : lang=" en ">The a c t i v i t i e s vocabulary encoding scheme</dc :

d e s c r i p t i on >4 <rd f s : subClassOf rd f : r e s ou r c e=" http ://www.w3 . org /2004/02/ skos / core#Concept "/>5 <owl : equ iva l entC la s s>6 <owl : Re s t r i c t i on>7 <owl : onProperty rd f : r e s ou r c e=" http ://www.w3 . org /2004/02/ skos / core#inScheme "

/>8 <owl : hasValue rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l / standard / a c t i v i t i e s "/>9 </owl : Re s t r i c t i on>10 </owl : equ iva l entC la s s>11 </rd f : Descr ipt ion>1213 <rd f : Des c r ip t i on rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ LegalForm ">14 <rd f s : l a b e l xml : lang=" en ">Legal Form VES</rd f s : l abe l >15 <dc : d e s c r i p t i o n xml : lang=" en ">The l e g a l form vocabulary encoding scheme</dc :


/>20 <owl : hasValue rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l / standard / l e ga l −form "/>21 </owl : Re s t r i c t i on>22 </owl : equ iva l entC la s s>23 </rd f : Descr ipt ion>2425 <rd f : Des c r ip t i on rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Qua l i f i e r s ">26 <rd f s : l a b e l xml : lang=" en ">Qua l i f i e r s VES</rd f s : l abe l >27 <dc : d e s c r i p t i o n xml : lang=" en ">The q u a l i f i e r s vocabulary encoding scheme</dc :


/>32 <owl : hasValue rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l / standard / q u a l i f i e r s "/>33 </owl : Re s t r i c t i on>34 </owl : equ iva l entC la s s>35 </rd f : Descr ipt ion>3637 <rd f : Des c r ip t i on rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ TypeOfLabour ">38 <rd f s : l a b e l xml : lang=" en ">Type o f Labour VES</rd f s : l abe l >39 <dc : d e s c r i p t i o n xml : lang=" en ">The type o f labour vocabulary encoding scheme</dc :

d e s c r i p t i on >



40 <rd f s : subClassOf rd f : r e s ou r c e=" http ://www.w3 . org /2004/02/ skos / core#Concept "/>41 <owl : equ iva l entC la s s>42 <owl : Re s t r i c t i on>43 <owl : onProperty rd f : r e s ou r c e=" http ://www.w3 . org /2004/02/ skos / core#inScheme "

/>44 <owl : hasValue rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l / standard /type−of−

l abour "/>45 </owl : Re s t r i c t i on>46 </owl : equ iva l entC la s s>47 </rd f : Descr ipt ion>

De seguida apresentamos a codificação RDF/XML relativa à criação das DataType properties(owl:DataTypeProperty) das classes do vocabulário ESSGlobal.

• Propriedade objective. Propriedade das classes SSEInitiative e Network:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ob j e c t i v e ">

2 <rd f s : l a b e l xml : lang=" en ">Object ive </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">Act ionable and measurable s t ep s the SSE

I n i t i a t i v e i s tak ing to car ry out i t s miss ion . </dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain>7 <owl : Class>8 <owl : unionOf>9 <rd f : Descr ipt ion>

10 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/SSEIn i t i a t i v e "/>

11 <rd f : r e s t>12 <rd f : Descr ipt ion>13 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1

.0/ Network "/>14 <rd f : r e s t rd f : r e s ou r c e=" http ://www.w3 . org /1999/02/22− rdf−

syntax−ns#n i l "/>15 </rd f : Descr ipt ion>16 </rd f : r e s t>17 </rd f : Descr ipt ion>18 </owl : unionOf>19 </owl : Class>20 </rd f s : domain>21 </owl : DatatypeProperty>

• Propriedade mission. Propriedade das classes SSEInitiative e Network:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ miss ion">

2 <rd f s : l a b e l xml : lang=" en ">Mission</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The i n i t i a t i v e ’ s v i s i on , values , and

p r i n c i p l e s .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/"/>



5 <rd f s : range rd f : r e s ou r c e="http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain>7 <owl : Class>8 <owl : unionOf>9 <rd f : Descr ipt ion>

10 <rd f : f i r s t rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/SSEIn i t i a t i v e "/>

11 <rd f : r e s t>12 <rd f : Descr ipt ion>13 <rd f : f i r s t rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1

.0/ Network"/>14 <rd f : r e s t rd f : r e s ou r c e="http ://www.w3 . org /1999/02/22− rdf−

syntax−ns#n i l "/>15 </rd f : Descr ipt ion>16 </rd f : r e s t>17 </rd f : Descr ipt ion>18 </owl : unionOf>19 </owl : Class>20 </rd f s : domain>21 </owl : DatatypeProperty>

• Propriedade economicSector. Propriedade da classe SSEInitiative:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/economicSector ">

2 <rd f s : l a b e l xml : lang=" en ">Economic Sector </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">A ca t e g o r i z a t i o n o f the type o f

a c t i v i t i e s c a r r i e d on by SSE i n i t i a t i v e s , depending o f i t s nature , rawmate r i a l s and methodology .</dcterms : d e s c r i p t i on >

4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ A c t i v i t i e s / "

/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

SSEIn i t i a t i v e "/>7 </owl : DatatypeProperty>

• Propriedade totalWomen. Propriedade da classe SSEInitiative:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/totalWomen ">

2 <rd f s : l a b e l xml : lang=" en ">Total o f Women</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The number o f women that work in the SSE

I n i t i a t i v e .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/


• Propriedade totalMen. Propriedade da classe SSEInitiative:



1 <owl : DatatyypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/totalMen ">

2 <rd f s : l a b e l xml : lang=" en ">Total o f Men</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The number o f men that work in the SSE

I n i t i a t i v e .</dcterms : d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/


• Propriedade totalOfMembers. Propriedade da classe SSEInitiative:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/totalOfMembers ">

2 <rd f s : l a b e l xml : lang=" en ">Total o f Members</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The t o t a l number o f members that work in

the SSE I n i t i a t i v e .</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/


• Propriedade legalForm. Propriedade da classe SSEInitiative e Network:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/legalForm ">

2 <rd f s : l a b e l xml : lang=" en ">Legal Form</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The l e g a l form o f a SSE I n i t i a t i v e or

Network .To be de s c r ibed .</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ LegalForm/ "

/>6 <rd f s : domain>7 <owl : Class>8 <owl : unionOf>9 <rd f : Descr ipt ion>

10 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/SSEIn i t i a t i v e "/>

11 <rd f : r e s t>12 <rd f : Descr ipt ion>13 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1

.0/ Network "/>14 <rd f : r e s t rd f : r e s ou r c e=" http ://www.w3 . org /1999/02/22− rdf−

syntax−ns#n i l "/>15 </rd f : Descr ipt ion>16 </rd f : r e s t>17 </rd f : Descr ipt ion>18 </owl : unionOf>



19 </owl : Class>20 </rd f s : domain>21 </owl : DatatypeProperty>

• Propriedade qualifier. Propriedade das classes ProductOrService e Input:1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

q u a l i f i e r ">2 <rd f s : l a b e l xml : lang=" en ">Qua l i f i e r </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">4 Aspect that d i f f e r e n t i a t e s the product or s e r v i c e o f an SSE i n i t i a t i v e

which i s r e l a t e d to the form o f production , the a c t o r s involved , theuse o f only organ i c mater ia l s , e t c .

5 Examples are organic , permacultura l , made with r e cy c l ed raw mater ia l s ,indigenous , made by women , e t c .

6 </dcterms : d e s c r i p t i on>7 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>8 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Qua l i f i e r s / "

/>9 <rd f s : domain>

10 <owl : Class>11 <owl : unionOf>12 <rd f : Descr ipt ion>13 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

ProductOrService "/>14 <rd f : r e s t>15 <rd f : Descr ipt ion>16 <rd f : f i r s t rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

Input "/>17 <rd f : r e s t rd f : r e s ou r c e=" http ://www.w3 . org /1999/02/22− rdf−syntax

−ns#n i l "/>18 </rd f : Descr ipt ion>19 </rd f : r e s t>20 </rd f : Descr ipt ion>21 </owl : unionOf>22 </owl : Class>23 </rd f s : domain>24 </owl : DatatypeProperty>

• Propriedade isAvailable. Propriedade da classe SaleOption:1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

i sAva i l a b l e ">2 <rd f s : l a b e l xml : lang=" en ">I s ava i l ab l e </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">I f the Sa le Option ( the product / s e r v i c e

at a c e r t a i n pr i ce , under s p e c i f i c p rope r t i e s , in a s p e c i f i c Sa l eLocat ion ) i s a v a i l a b l e .</dcterms : d e s c r i p t i on>

4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#boolean "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ SaleOption "

/>



7 </owl : DatatypeProperty>

• Propriedade saleMarginPercentage. Propriedade da classe SaleOption:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/sa le sMarg inPercentage ">

2 <rd f s : l a b e l xml : lang=" en ">Sa l e s Margin ( percentage )</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">4 Margin ( on s a l e s ) i s the d i f f e r e n c e between s e l l i n g p r i c e and co s t . This

d i f f e r e n c e i s t y p i c a l l y expres sed e i t h e r as a percentage o f s e l l i n gp r i c e or on a per−uni t ba s i s . This a t t r i b u t e i s the percentage s a l e smargin .

5 </dcterms : d e s c r i p t i on>6 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>7 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>8 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ SaleOption "

/>9 </owl : DatatypeProperty>

• Propriedade salesMarginValue. Propriedade da classe SaleOption:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/sa lesMarginValue ">

2 <rd f s : l a b e l xml : lang=" en ">Sa l e s Margin ( va lue )</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">4 Margin ( on s a l e s ) i s the d i f f e r e n c e between s e l l i n g p r i c e and co s t . This

d i f f e r e n c e i s t y p i c a l l y expres sed e i t h e r as a percentage o f s e l l i n gp r i c e or on a per−uni t ba s i s . The pre sent a t t r i b u t e i s an abso lu t eva lue for s a l e s margin on each un i t o f the product or s e r v i c e o f f e r e din the l o c a t i o n .

5 </dcterms : d e s c r i p t i on>6 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>7 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>8 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ SaleOption "

/>9 </owl : DatatypeProperty>

• Propriedade state. Propriedade da classe LocationOfSale:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ s t a t e ">2 <rd f s : l a b e l xml : lang=" en ">State</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The State where the Locat ion o f Sa l e i s

l o ca t ed .</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

Locat ionOfSale "/>7 </owl : DatatypeProperty>

• Propriedade isMain. Propriedade da classe LocationOfSale:



1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab /1 .0/ isMain ">2 <rd f s : l a b e l xml : lang=" en ">I s Main</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">I f the Locat ion o f Sa l e i s the

headquarter o f the SSE i n i t i a t i v e ?</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab /1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#boolean " />6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/


• Propriedade isSSE. Propriedade da classe LocationOfSale:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ isSSE ">2 <rd f s : l a b e l xml : lang=" en ">I s SSE I n i t i a t i v e </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">I f the Locat ion o f Sa l e i s a p lace

be long ing to the SSE.</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#boolean "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/


• Propriedade deliveryRangeDistance. Propriedade da classe LocationOfSale:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/de l iveryRangeDistance ">

2 <rd f s : l a b e l xml : lang=" en ">De l ive ry Range ( d i s t ance )</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">De l ive ry range o f product or s e r v i c e , in

k i l omet e r s or mi l e s .</dcterms : d e s c r i p t i on>4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/


• Propriedade quantityPerProductOrServiceUnit. Propriedade da classe Input:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/quant ityPerProductOrServiceUnit ">

2 <rd f s : l a b e l xml : lang=" en ">Quantity per Product or Se rv i c e Unit</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The quant i ty o f the input that goes in to

prov id ing one un i t o f the f i n a l product or s e r v i c e .</dcterms :d e s c r i p t i on >

4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Input "/>7 </owl : DatatypeProperty>

• Propriedade costPerUnit. Propriedade da classe Input:



1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/costPerUnit ">

2 <rd f s : l a b e l xml : lang=" en ">Cost per Unit</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The co s t per un i t o f input .</dcterms :

d e s c r i p t i on >4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Input "/>7 </owl : DatatypeProperty>

• Propriedade unit. Propriedade da classe Input:

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ un i t ">2 <rd f s : l a b e l xml : lang=" en ">Unit</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The uni t that a product or s e r v i c e i s

measured in , in the Unive r sa l Unit System ( e . g . , k i lograms , hours )</dcterms : d e s c r i p t i on>

4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http ://www.w3 . org /2000/01/ rdf−schema#L i t e r a l " />6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Input " />7 </rowl : DatatypeProperty>

• Propriedade hasImpactOnCost. Propriedade das classes Input e OtherCosts:

1 <owl : DatatypePropertyrdf : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/hasImpactOnCost ">

2 <rd f s : l a b e l xml : lang=" en ">Has impact on cost </rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">Does the input con t r i bu t e to the

monetary p r i c e o f the f i n a l product ? Whereas many ( perhaps most ) inputsdo con t r i bu t e to the monetary p r i c e o f the f i n a l product or s e r v i c e ,

some don ’ t . For example , vo luntee r labour may cont r i bu t e g r e a t l y toproduct ion without adding to the monetary co s t o f product ion .</dcterms :d e s c r i p t i on >

4 <rd f s : i sDef inedBy rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/"/>5 <rd f s : range rd f : r e s ou r c e="http ://www.w3 . org /2000/01/ rdf−schema#boolean " />6 <rd f s : domain>7 <owl : Class>8 <owl : unionOf>9 <rd f : Descr ipt ion>

10 <rd f : f i r s t rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Input"/>

11 <rd f : r e s t>12 <rd f : Descr ipt ion>13 <rd f : f i r s t rd f : r e s ou r c e="http :// pur l . org / e s s g l o b a l /vocab/v1 .0/

OtherCosts "/>14 <rd f : r e s t rd f : r e s ou r c e="http ://www.w3 . org /1999/02/22− rdf−syntax

−ns#n i l "/>15 </rd f : Descr ipt ion>16 </rd f : r e s t>17 </rd f : Descr ipt ion>



18 </owl : unionOf>19 </owl : Class>20 </rd f s : domain>21 </owl : DatatypeProperty>

• Propriedade typeOfLabour. Propriedade da classe Labour :

1 <owl : DatatypeProperty rd f : about=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/typeOfLabour ">

2 <rd f s : l a b e l xml : lang=" en ">Type o f Labour</rd f s : l abe l >3 <dcterms : d e s c r i p t i o n xml : lang=" en ">The human labour ded icated for prov id ing

goods or s e r v i c e s can be o f d i f f e r e n t types , depending on thee s t ab l i s h ed labour r e l a t i o n s . For example , i t might be a s s o c i a t i v e ( i . e. , the worker i s one o f the c o l l e c t i v e owners o f the SSE i n i t i a t i v e ) ,but i t might a l s o be subord inated work ( an employee o f the SSEi n i t i a t i v e ) , vo luntee r work or e x t e r n a l l y h i r ed work ( l i k e a f r e e l a n c e ror a partner i n i t i a t i v e ) .</dcterms : d e s c r i p t i on>

4 <rd f s : i sDef inedBy rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ "/>5 <rd f s : range rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ TypeOfLabour

/ "/>6 <rd f s : domain rd f : r e s ou r c e=" http :// pur l . org / e s s g l o b a l /vocab/v1 .0/ Labour "/>7 </owl : DatatypeProperty>

A Figura 6.26 apresenta o grafo com as propriedades (owl:DataTypeProperty) do vocabulárioESSGlobal das classes SSEInitiative e Network.

A Figura 6.27 apresenta o grafo com as propriedades (owl:DataTypeProperty) do vocabulárioESSGlobal das classes ProductOrService, Input e OtherCosts.

A Figura 6.28 apresenta o grafo com as propriedades (owl:DataTypeProperty) do vocabulárioESSGlobal das classes SaleOption e Labour.

A Figura 6.29 apresenta o grafo com as propriedades (owl:DataTypeProperty) do vocabulárioESSGlobal da classe LocationOfSale.

O grafo completo pode ser descarregado em formato png no endereço: http://www.purl.

org/essglobal/vocab-V1-graph.A codificação completa em RDF/XML do vocabulário ESSGlobal V1.0 está disponível no

endereço http://purl.org/essglobal/vocab/v1.0/.Relativamente aos vocabulários controlados:• As listas controladas de termos desenvolvidas pelo consórcio RIPESS na fase 1 dos trabalhos(c.f. Secção B.1) foram codificadas em SKOS por alunos da Universidade do Minho, noâmbito do projecto da Unidade Curricular ”Web semântica“ (2010/2011) do Mestrado deSistemas de Informação.67;

• A lista controlada de Produtos e Serviços foi por nós codificada em SKOS;

67Elementos do grupo: César Araujo, Leonardo Cruz, Rodrigo Alves e Sergio Vale; orientação Prof. DoutoraAna Alice Baptista.


http://www.purl.org/essglobal/vocab-V1-graph

http://www.purl.org/essglobal/vocab-V1-graph

http://purl.org/essglobal/vocab/v1.0/


• Na fase 2 dos trabalhos o grupo ESSGlobal identificou a necessidade de mais duas listascontroladas de termos: Estatuto Legal e Tipo de Trabalho. Estas listas foram criadas pelogrupo e depois codificadas por nós em SKOS.

A Tabela 6.20 apresenta os URI de cada um dos Esquemas de codificação de vocabuláriodefinidos.

Tabela 6.20: Os esquemas de codificação de vocabulário desenvolvidos para servir o Dublin CoreApplication Profile-Economia Social e Solidária

Nome URIActividades http://purl.org/essglobal/standard/activitiesEstatuto Legal http://purl.org/essglobal/standard/legal-formQualificadores http://purl.org/essglobal/standard/qualifiersProdutos e Serviços http://purl.org/essglobal/standard/products-servicesTemas http://purl.org/essglobal/standard/themesTipo de Trabalho http://purl.org/essglobal/standard/type-of-labour



Figura 6.26: Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal das classes SSEInitiative e Network.

Figura 6.27: Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal das classes ProductOrService, Input e OtherCosts.

Figura 6.28: Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal das classes SaleOption e Labour.



Figura 6.29: Grafo com as propriedades (owl:DataTypeProperty) do vocabulário ESSGlobal da classe LocationOfSale.



6.4.4 Description Set Profile

Uma vez que não foi realizado ainda, no momento da escrita desta Tese, o conjunto de actividadesjá referidas, o deliverable aqui apresentado está numa versão sujeita a alterações futuras68,sobretudo depois da actividade de validação em laboratório.

O código seguinte apresenta o DSP na sua codificação XML. Este código está disponível noURL: http://purl.org/essglobal/dsp-xml.

1 <?xml ve r s i on=" 1 .0 " ?>2 <Descr ipt ionSetTemplate xmlns=" http :// dub l inco re . org /xml/dc−dsp /2008/03/31 ">34 <Descr ipt ionTemplate ID=" SSEIn i t i a t i v e " minOccur=" 1 " maxOccur=" i n f i n i t y "

s tanda lone=" yes ">5 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ SSEIn i t i a t i v e </

ResourceClass>67 <StatementTemplate ID="Name" minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">8 <Property>http : // pur l . org / good r e l a t i on s /v1#name</Property>9 </StatementTemplate>1011 <StatementTemplate ID=" Desc r ip t i on " minOccurs=" 0 " maxOccurs=" 1 " type="

l i t e r a l ">12 <Property>http : //www. pur l . org /dc/ terms/ de s c r i p t i on </Property>13 <L i t e r a lCons t r a in t >14 <LanguageOccurrence>opt iona l </LanguageOccurrence>15 </L i t e r a lCons t r a in t >16 </StatementTemplate>1718 <StatementTemplate ID=" Object ive " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l

">19 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ o b j e c t i v e </Property>20 <L i t e r a lCons t r a in t >21 <LanguageOccurrence>opt iona l </LanguageOccurrence>22 </L i t e r a lCons t r a in t >23 </StatementTemplate>2425 <StatementTemplate ID=" Miss ion " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">26 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ mission</Property>27 <L i t e r a lCons t r a in t >28 <LanguageOccurrence>opt iona l </LanguageOccurrence>29 </L i t e r a lCons t r a in t >30 </StatementTemplate>3132 <StatementTemplate ID="Type " minOccurs=" 0 " maxOccurs=" i n f i n i t y " type="

n o n l i t e r a l ">33 <Property>http : //www. pur l . org /dc/ terms/ type</Property>34 <NonLitera lConstra int>35 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / themes/</

VocabularyEncodingSchemeURI>

68Para uma actualização da informação consultar Wiki do projecto: http://purl.org/essglobal/wiki


http://purl.org/essglobal/dsp-xml



36 </NonLitera lConstra int>37 </StatementTemplate>3839 <StatementTemplate ID="Economic−Sector " minOccurs=" 0 " maxOccurs=" i n f i n i t y "

type=" n o n l i t e r a l ">40 <Property>http : //www. pur l . org / e s s g l o b a l / vocab/v1 .0/ economicSector</Property>41 <NonLitera lConstra int>42 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / a c t i v i t i e s />

VocabularyEncodingSchemeURI>43 </NonLitera lConstra int>44 </StatementTemplate>4546 <StatementTemplate ID=" totalWomen " minOccurs=" 0 " maxOccurs=" 1 " type="

l i t e r a l ">47 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ totalWomen</Property>48 </StatementTemplate>4950 <StatementTemplate ID=" totalMen " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l "

>51 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/TotalMen</Property>52 </StatementTemplate>5354 <StatementTemplate ID=" Total−of−Members " minOccurs=" 0 " maxOccurs=" 1 " type="

l i t e r a l ">55 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ totalOfMembers</Property>56 </StatementTemplate>5758 <StatementTemplate ID="URL" minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">59 <Property>http : // pur l . org / good r e l a t i on s /v1#homepage</Property>60 </StatementTemplate>6162 <StatementTemplate ID=" Legal−Form" minOccurs=" 0 " maxOccurs=" 1 " type="

n o n l i t e r a l ">63 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ legalForm</Property>64 <NonLitera lConstra int>65 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / l e g a l −

form/</VocabularyEncodingSchemeURI>66 </NonLitera lConstra int>67 </StatementTemplate>6869 <StatementTemplate ID=" has−Product−or−Se rv i c e " minOccurs=" 0 " maxOccurs="

i n f i n i t y " type=" n o n l i t e r a l ">70 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasProductOrService</

Property>71 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Product−or−Se rv i c e "/>72 </StatementTemplate>7374 <StatementTemplate ID=" Is−part−of−a−Network " minOccurs=" 0 " maxOccurs="

i n f i n i t y " type=" n o n l i t e r a l ">75 <Property>http : // pur l . org /dc/ terms/ isPartOf </Property>



76 <NonLi te ra lConst ra int descr ipt ionTemplateRef="Network "/>77 </StatementTemplate>7879 </Descr ipt ionTemplate>8081 <Descr ipt ionTemplate ID="Network " minOccur=" 0 " maxOccur=" i n f i n i t y " s tanda lone=" yes

">82 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ Network</ResourceClass>8384 <StatementTemplate ID="Name" minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">85 <Property>http : // pur l . org / good r e l a t i on s /v1#name</Property>86 </StatementTemplate>8788 <StatementTemplate ID=" Desc r ip t i on " minOccurs=" 0 " maxOccurs=" 1 " type="

l i t e r a l ">89 <Property>http : //www. pur l . org /dc/ terms/ de s c r i p t i on </Property>90 <L i t e r a lCons t r a in t >91 <LanguageOccurrence>opt iona l </LanguageOccurrence>92 </L i t e r a lCons t r a in t >93 </StatementTemplate>9495 <StatementTemplate ID=" Object ive " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l

">96 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ o b j e c t i v e </Property>97 <L i t e r a lCons t r a in t >98 <LanguageOccurrence>opt iona l </LanguageOccurrence>99 </L i t e r a lCons t r a in t >

100 </StatementTemplate>101102 <StatementTemplate ID=" Miss ion " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">103 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ mission</Property>104 <L i t e r a lCons t r a in t >105 <LanguageOccurrence>opt iona l </LanguageOccurrence>106 </L i t e r a lCons t r a in t >107 </StatementTemplate>108109 <StatementTemplate ID="URL" minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">110 <Property>http : // pur l . org / good r e l a t i on s /v1#homepage</Property>111 </StatementTemplate>112113 <StatementTemplate ID=" Legal−Form" minOccurs=" 0 " maxOccurs=" 1 " type="

n o n l i t e r a l ">114 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ legalForm</Property>115 <NonLitera lConstra int>116 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / l e g a l −

form/</VocabularyEncodingSchemeURI>117 </NonLitera lConstra int>118 </StatementTemplate>119120 <StatementTemplate ID=" has−Product−or−Se rv i c e " minOccurs=" 0 " maxOccurs="



i n f i n i t y " type=" n o n l i t e r a l ">121 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasProductOrService</

Property>122 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Product−or−Se rv i c e "/>123 </StatementTemplate>124125 <StatementTemplate ID=" Is−made−of−SSE−I n i t i a t i v e s " minOccurs=" 1 "

maxOccurs=" i n f i n i t y " type=" n o n l i t e r a l ">126 <Property>http : // pur l . org /dc/ terms/hasPart</Property>127 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" SSEIn i t i a t i v e "/>128 </StatementTemplate>129130131 </Descr ipt ionTemplate>132133134 <Descr ipt ionTemplate ID=" Product−or−Se rv i c e " minOccur=" 0 " maxOccur=" i n f i n i t y "

s tanda lone=" yes ">135 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ ProductOrService</

ResourceClass>136137 <StatementTemplate ID="Name" minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">138 <Property>http : // pur l . org / good r e l a t i on s /v1#name</Property>139 </StatementTemplate>140141 <StatementTemplate ID=" Desc r ip t i on " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l

">142 <Property>http : //www. pur l . org /dc/ terms/ de s c r i p t i on </Property>143 <L i t e r a lCons t r a in t >144 <LanguageOccurrence>opt iona l </LanguageOccurrence>145 </L i t e r a lCons t r a in t >146 </StatementTemplate>147148 <StatementTemplate ID=" Category " minOccurs=" 0 " maxOccurs=" i n f i n i t y " type="

l i t e r a l ">149 <Property>http : // pur l . org / good r e l a t i on s /v1#category </Property>150 <NonLitera lConstra int>151 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / products

−s e r v i c e s /</VocabularyEncodingSchemeURI>152 </NonLitera lConstra int>153 </StatementTemplate>154155 <StatementTemplate ID=" Qua l i f i e r " minOccurs=" 0 " maxOccurs=" i n f i n i t y " type="

n o n l i t e r a l ">156 <Property>http : //www. pur l . org / e s s g l o b a l / vocab/v1 .0/ q u a l i f i e r </Property>157 <NonLitera lConstra int>158 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / q u a l i f i e r /</

VocabularyEncodingSchemeURI>159 </NonLitera lConstra int>160 </StatementTemplate>



161162 <StatementTemplate ID=" Image " minOccurs=" 0 " maxOccurs=" 1 " type=" n o n l i t e r a l ">163 <Property>http : //xmlns . com/ f o a f /0.1/ dep i c t s </Property>164 </StatementTemplate>165166 <StatementTemplate ID=" Unit " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">167 <Property>http : // pur l . org / good r e l a t i on s /v1#hasUnitOfMeasurement</Property>168 </StatementTemplate>169170 <StatementTemplate ID=" has−sa l e−Option " minOccurs=" 0 " maxOccurs=" i n f i n i t y "

type=" n o n l i t e r a l ">171 <Property>http : //www. pur l . org / e s s g l o b a l / vocab/v1 .0/ hasSaleOption</

Property>172 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Sale−Option "/>173 </StatementTemplate>174175 <StatementTemplate ID=" has−Cost " minOccurs=" 0 " maxOccurs=" 1 " type=" n o n l i t e r a l "

>176 <Property>http : //www. pur l . org / e s s g l o b a l / vocab/v1 .0/ hasCost</Property>177 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Cost "/>178 </StatementTemplate>179180 </Descr ipt ionTemplate>181182183 <Descr ipt ionTemplate ID=" Sale−Option " minOccur=" 0 " maxOccur=" i n f i n i t y " s tanda lone=

" no ">184185 <StatementTemplate ID=" i s a v a i l a b l e " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l

">186 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ i sAva i l a b l e </Property>187 <L i t e r a lCons t r a in t >188 <SyntaxEncodingScheme>http : //schema . org /Boolean</SyntaxEncodingScheme>189 </L i t e r a lCons t r a in t >190 </StatementTemplate>191192 <StatementTemplate ID=" Sales−Margin−Percentage " minOccurs=" 1 " maxOccurs="

1 " type=" l i t e r a l ">193 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ sa lesMarginPercentage </Property

>194 </StatementTemplate>195196 <StatementTemplate ID=" Sales−Margin−Value " minOccurs=" 1 " maxOccurs=" 1 " type="

l i t e r a l ">197 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ salesMarginValue</Property>198 </StatementTemplate>199200 <StatementTemplate ID=" Del ivery−Cost " minOccurs=" 1 " maxOccurs=" 1 " type="

l i t e r a l ">201 <Property>http : // pur l . org / good r e l a t i on s /v1#hasCurrencyPrice</Property>



202 </StatementTemplate>203204 <StatementTemplate ID=" Pr i ce " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">205 <Property>http : // pur l . org / g ood r e l a t i on s /v1#hasCurrencyPrice</Property>206 </StatementTemplate>207208 <StatementTemplate ID=" i s−ava i l ab l e−at−a−Location−of−Sa le " minOccurs=" 1 " maxOccurs

=" 1 " type=" n o n l i t e r a l ">209 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ i sAva i l a b l eA t </Property

>210 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Location−of−Sa le "/>211 </StatementTemplate>212213 </Descr ipt ionTemplate>214215216 <Descr ipt ionTemplate ID=" Location−of−Sa le " minOccur=" 0 " maxOccur=" i n f i n i t y "

s tanda lone=" yes ">217 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ LocationOfSale </

ResourceClass>218219 <StatementTemplate ID="Name" minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">220 <Property>http : //www. pur l . org /dc/ terms/ t i t l e </Property>221 </StatementTemplate>222223 <StatementTemplate ID=" Address " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">224 <Property>http : //www.w3 . org /2006/ vcard /ns/ s t r e e t −address </Property>225 </StatementTemplate>226227 <StatementTemplate ID=" Zip−Code " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">228 <Property>http : //www.w3 . org /2006/ vcard /ns/ pos ta l−code</Property>229 </StatementTemplate>230231 <StatementTemplate ID=" State " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">232 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ s t a t e </Property>233 </StatementTemplate>234235 <StatementTemplate ID=" City " minOccurs=" 0 " maxOccurs=" 1 " type=" n o n l i t e r a l ">236 <Property>http : //www.w3 . org /2006/ vcard /ns/ l o c a l i t y </Property>237 <NonLitera lConstra int>238 <VocabularyEncodingSchemeURI>http : // pur l . org /dc/ terms/TGN</

VocabularyEncodingSchemeURI>239 </NonLitera lConstra int>240 </StatementTemplate>241242 <StatementTemplate ID="Country " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">243 <Property>http : //www.w3 . org /2006/ vcard /ns/ country−name</Property>244 <L i t e r a lCons t r a in t >245 <SyntaxEncodingScheme>http : // pur l . org /dc/ terms/ISO3166</

SyntaxEncodingScheme>



246 </L i t e r a lCons t r a in t >247 </StatementTemplate>248249 <StatementTemplate ID=" isMain " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">250 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ isMain</Property>251 <L i t e r a lCons t r a in t >252 <SyntaxEncodingScheme>http : //schema . org /Boolean</SyntaxEncodingScheme>253 </L i t e r a lCons t r a in t >254 </StatementTemplate>255256257 <StatementTemplate ID=" isSSE " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">258 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ isSSE</Property>259 <L i t e r a lCons t r a in t >260 <SyntaxEncodingScheme>http : //schema . org /Boolean</SyntaxEncodingScheme>261 </L i t e r a lCons t r a in t >262 </StatementTemplate>263264265 <StatementTemplate ID="Mobile−Phone " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l "

>266 <Property>http : //schema . org / te l ephone </Property>267 </StatementTemplate>268269 <StatementTemplate ID="Phone " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">270 <Property>http : //schema . org / te l ephone </Property>271 </StatementTemplate>272273 <StatementTemplate ID=" Email " minOccurs=" 0 " maxOccurs=" 1 " type=" n o n l i t e r a l ">274 <Property>http : //xmlns . com/ f o a f /0.1/mbox</Property>275 <NonLitera lConstra int>276 <ValueURIOccurrence>mandatory</ValueURIOccurrence>277 </NonLitera lConstra int>278 </StatementTemplate>279280 <StatementTemplate ID="Fax " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">281 <Property>http : //schema . org / faxnumber</Property>282 </StatementTemplate>283284 <StatementTemplate ID=" Del ivery−Range−Distance " minOccurs=" 0 " maxOccurs=" 1 "

type=" l i t e r a l ">285 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ d e l i v e r y −range−d i s tance </

Property>286 </StatementTemplate>287288 <StatementTemplate ID=" Del ivery−Range−Geographic−Area " minOccurs=" 0 " maxOccurs=

" i n f i n i t y " type=" l i t e r a l ">289 <Property>http : // pur l . org / good r e l a t i on s /v1#e l i g i b l eR e g i o n s </Property>290 <L i t e r a lCons t r a in t >291 <SyntaxEncodingScheme>http : // pur l . org /dc/ terms/ISO3166</



SyntaxEncodingScheme>292 </L i t e r a lCons t r a in t >293 </StatementTemplate>294295 <StatementTemplate ID=" Longitude " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">296 <Property>http : //www.w3 . org /2006/ vcard /ns/ l o g i t ud e </Property>297 </StatementTemplate>298299 <StatementTemplate ID=" Lat i tude " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">300 <Property>http : //www.w3 . org /2006/ vcard /ns/ l a t i t u d e </Property>301 </StatementTemplate>302303 </Descr ipt ionTemplate>304305 <Descr ipt ionTemplate ID=" Cost " minOccur=" 0 " maxOccur=" 1 " standa lone=" no ">306 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ Cost</ResourceClass>307308 <StatementTemplate ID="Value " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">309 <Property>http : // pur l . org / good r e l a t i on s /v1#hasCurrencyValue</Property>310 </StatementTemplate>311312 <StatementTemplate ID=" Currency " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">313 <Property>http : // pur l . org / good r e l a t i on s /v1#hasCurrency</Property>314 </StatementTemplate>315316 <StatementTemplate ID=" i s−composed−by " minOccurs=" 0 " maxOccurs=" i n f i n i t y " type

=" n o n l i t e r a l ">317 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ isComposedBy</Property>318 <NonLi te ra lConst ra int descr ipt ionTemplateRef="Cost−Composition "/>319 </StatementTemplate>320321 </Descr ipt ionTemplate>322323324 <Descr ipt ionTemplate ID="Cost−Composition " minOccur=" 0 " maxOccur=" 1 " standa lone="

no ">325 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ CostComposition</

ResourceClass>326327 <StatementTemplate ID="Has−Input " minOccurs=" 0 " maxOccurs=" i n f i n i t y " type="

n o n l i t e r a l ">328 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasInputCost </Property>329 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Input "/>330 </StatementTemplate>331332 <StatementTemplate ID="Has−Labour " minOccurs=" 0 " maxOccurs=" i n f i n i t y " type="

n o n l i t e r a l ">333 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasLabourCost</Property>334 <NonLi te ra lConst ra int descr ipt ionTemplateRef=" Labour "/>335 </StatementTemplate>



336337 <StatementTemplate ID="Has−Other−Costs " minOccurs=" 0 " maxOccurs=" i n f i n i t y "

type=" n o n l i t e r a l ">338 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasOtherCosts</Property>339 <NonLi te ra lConst ra int descr ipt ionTemplateRef="Other−Costs "/>340 </StatementTemplate>341 </Descr ipt ionTemplate>342343344 <Descr ipt ionTemplate ID=" Input " minOccur=" 0 " maxOccur=" i n f i n i t y " s tanda lone=" no ">345 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ Input</ResourceClass>346347 <StatementTemplate ID=" Desc r ip t i on " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l

">348 <Property>http : // pur l . org /dc/ terms/ de s c r i p t i on </Property>349 <L i t e r a lCons t r a in t >350 <LanguageOccurrence>opt iona l </LanguageOccurrence>351 </L i t e r a lCons t r a in t >352 </StatementTemplate>353354 <StatementTemplate ID="Quantity−per−ProductOrService−Unit " minOccurs=" 1 "

maxOccurs=" 1 " type=" l i t e r a l ">355 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ quant i tyPerProductOrServ iceUnit

</Property>356 </StatementTemplate>357358 <StatementTemplate ID="Cost−per−Unit " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l

">359 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ costPerUnit </Property>360 </StatementTemplate>361362 <StatementTemplate ID=" Unit " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">363 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ unit </Property>364 </StatementTemplate>365366 <StatementTemplate ID=" Category " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">367 <Property>http : // pur l . org / good r e l a t i on s /v1#category </Property>368 <NonLitera lConstra int>369 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / products−

s e r v i c e s /</VocabularyEncodingSchemeURI>370 </NonLitera lConstra int>371 </StatementTemplate>372373 <StatementTemplate ID=" Qua l i f i e r " minOccurs=" 0 " maxOccurs=" 1 " type=" n o n l i t e r a l "

>374 <Property>http : //www. pur l . org / e s s g l o b a l / vocab/v1 .0/ q u a l i f i e r </Property>375 <NonLitera lConstra int>376 <VocabularyEncodingSchemeURI>http : // pur l . org / e s s g l o b a l / s tandard / q u a l i f i e r /</

VocabularyEncodingSchemeURI>377 </NonLitera lConstra int>



378 </StatementTemplate>379380 <StatementTemplate ID="Has−Impact−on−Pr ice " minOccurs=" 1 " maxOccurs=" 1 " type=

" l i t e r a l ">381 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasImpactOnPrice</Property>382 <L i t e r a lCons t r a in t >383 <SyntaxEncodingScheme>http : //schema . org /Boolean</SyntaxEncodingScheme>384 </L i t e r a lCons t r a in t >385 </StatementTemplate>386387 </Descr ipt ionTemplate>388389390391 <Descr ipt ionTemplate ID=" Labour " minOccur=" 0 " maxOccur=" i n f i n i t y " s tanda lone=" no ">392 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ Labour</ResourceClass>393394 <StatementTemplate ID=" Desc r ip t i on " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">395 <Property>http : // pur l . org /dc/ terms/ de s c r i p t i on </Property>396 <L i t e r a lCons t r a in t >397 <LanguageOccurrence>opt iona l </LanguageOccurrence>398 </L i t e r a lCons t r a in t >399 </StatementTemplate>400401 <StatementTemplate ID="Type " minOccurs=" 0 " maxOccurs=" 1 " type=" l i t e r a l ">402 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ typeOfLabour<Property>403 </StatementTemplate>404405406 <StatementTemplate ID=" Contr ibut ion−to−the−Cost " minOccurs=" 1 " maxOccurs=" 1 "

type=" l i t e r a l ">407 <Property>http : // pur l . org / good r e l a t i on s /v1#hasCurrencyValue</Property>408 </StatementTemplate>409410 </Descr ipt ionTemplate>411412413 <Descr ipt ionTemplate ID="Other−Costs " minOccur=" 0 " maxOccur=" i n f i n i t y " s tanda lone=

" no ">414 <ResourceClass>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ OtherCosts</ResourceClass>415416 <StatementTemplate ID=" Desc r ip t i on " minOccurs=" 1 " maxOccurs=" 1 " type=" l i t e r a l ">417 <Property>http : // pur l . org /dc/ terms/ de s c r i p t i on </Property>418 <L i t e r a lCons t r a in t >419 <LanguageOccurrence>opt iona l </LanguageOccurrence>420 </L i t e r a lCons t r a in t >421 </StatementTemplate>422423 <StatementTemplate ID=" Contr ibut ion−to−the−Cost " minOccurs=" 1 " maxOccurs=" 1 "

type=" l i t e r a l ">



424 <Property>http : // pur l . org / good r e l a t i on s /v1#hasCurrencyValue</Property>425 </StatementTemplate>426427428 <StatementTemplate ID="Has−Impact−on−Pr ice " minOccurs=" 1 " maxOccurs=" 1 " type="

l i t e r a l ">429 <Property>http : // pur l . org / e s s g l o b a l / vocab/v1 .0/ hasImpactOnPrice</Property>430 <L i t e r a lCons t r a in t >431 <SyntaxEncodingScheme>http : //schema . org /Boolean</SyntaxEncodingScheme>432 </L i t e r a lCons t r a in t >433 </StatementTemplate>434435 </Descr ipt ionTemplate>436437438 </Descr ipt ionSetTemplate>

6.5 Desenvolver os Guias de Utilização e os Guias de Sintaxe

Estas actividades estão ainda a decorrer no momento de escrita desta Tese e por isso os artefactosmencionados não são apresentados69. De salientar que os deliverables a produzir nestas Etapasde Singapura estão definidos como não obrigatórios no Enquadramento de Singapura.

6.6 Sumário

Este capítulo tem como objectivo a apresentação do desenvolvimento do DCAP-ESS segundo ométodo Me4DCAP (ver capítulo 5). Este trabalho foi executado em conjunto com um grupopertencente à organização mundial RIPESS da ESS mundial. Este grupo deseja partilhar ainformação contida nos seus SIW a uma escala global, desejando ainda que estes SIW estejamtambém disponíveis para a função de descoberta da WS. A RIPESS deseja alcançar uma grandevisibilidade mundial, de forma a mostrar a real dimensão da ESS.

O trabalho apresentado neste capítulo consiste na execução das actividades referidas noMe4DCAP, desenvolvendo assim os artefactos e os deliverables definidos pelo método - obtendocomo resultado o DCAP-ESS V1.0.

Este trabalho é considerado em termos metodológicos a ”situação experimental“ do ciclode Design do enquadramento específico de DSR - definido por Hevner (2007) (ver Secção 3.3) -por nós escolhido. Ele serviu para, além de apresentar uma solução para o problema do grupoda RIPESS, desenvolver também o método Me4DCAP, o principal resultado deste trabalho dedoutoramento. Deu-nos a possibilidade da execução de ciclos de construção e de avaliação doMe4DCAP, apurando em cada ciclo a sua concepção.

69Para uma actualização da informação consultar o Wiki do projecto: http://purl.org/essglobal/wiki



Capítulo 7

Considerações finais

VERIFYVerify what you learn.To find the kernels of truth is hard indeed.

Deng Ming-Dao

Este capítulo encerra esta Tese de doutoramento recordando o processo de desenvolvimento dotrabalho, identificando o problema a resolver e a oportunidade encontrada; apresentando ainda osprincipais contributos dados, e as limitações do trabalho realizado. O capítulo termina revelandoas perspectivas futuras de trabalho que nasceram da investigação realizada.

7.1 Introdução

Um Dublin Core Application Profile (DCAP) é “um constructo genérico para desenhar registosde metadados” Baker and Coyle (2009). Segundo a Dublin Core Metadata Initiative (DCMI)a comunidade que possua um DCAP e o utilize como referência e ligação para descrever osseus recursos, alcançará o mais elevado nível de interoperabilidade semântica entre os seussistemas. Por essa razão o DCAP é um constructo muito importante. As organizações necessitamde modelos de dados que apoiem as suas necessidades de interoperabilidade, e a concepção,desenvolvimento e implementação desses modelos, sendo um processo complexo, necessita deum suporte metodológico. No sentido de encontrar esse suporte metodológico, elaboramos umestudo que resultou no estado da arte dos métodos para o desenvolvimento de Perfil de Aplicaçãode metadados (PA). A conclusão deste estudo foi que, tanto quanto foi possível apurar, nãoexiste nenhum método para o desenvolvimento de um PA. A ausência de um tal método é umproblema na comunidade de metadados dada a importância da Web e a grande actividade dosseus agentes. Esta tese de doutoramento resolveu este problema concebendo um método para odesenvolvimento de DCAP.

O Método para o desenvolvimento de Dublin Core Application Profiles (Me4DCAP) foidesenvolvido tendo como base a metodologia de investigação Design Science Research (DSR) noenquadramento particular de Hevner (2007). Esse desenvolvimento foi alimentado por:

227

7. Considerações finais

• as primeiras fases (até à modelação de dados) dos métodos de desenvolvimento de software;• os resultados das entrevistas realizadas a pessoas que desenvolveram DCAP, que tiveram

como objectivo entender as práticas utilizadas no desenvolvimento dos seus DCAP, e;• as práticas identificadas na realização do estado da arte dos métodos para desenvolvimentode perfis de aplicação de metadados;

O Me4DCAP tem como base o Enquadramento de Singapura - ver Nilsson et al. (2008) - ecomo ponto de partida o Rational Unified Process (RUP) - ver Kruchten (2004) - , um dos maisconhecidos e utilizados processos de desenvolvimento de software. O Me4DCAP foi desenvolvidotendo como suporte uma situação experimental“ Hevner (2007). A ”situação experimental“serve, segundo Hevner (2007), como momento de avaliação nos ciclos de construção-avaliação daconcepção do Me4DCAP, de forma a ir depurando a concepção com testes de avaliação numasituação da vida real. A ”situação experimental” foi o desenvolvimento de um Dublin CoreApplication Profile para os Sistemas de Informação Web da comunidade mundial de EconomiaSocial e Solidária (DCAP-ESS). Realizamos um estudo aos Sistemas de Informação Web (SIW)de um grupo representativo da comunidade Economia Social e Solidária (ESS) para entendermosas necessidades desses SIW, e concluimos que este grupo quer partilhar dados a nível internacionalatravés dos seus SIW, assim como colocar os seus SIW disponíveis para a função de descobertana Web Semântica (WS). Assim, identificamos uma oportunidade: esta comunidade necessitade um DCAP para responder às necessidades de interoperabilidade dos seus SIW. Com oestudo que realizamos dos PA a nível mundial, verificamos que não existe nenhum esquema demetadados, nem nenhum PA que possa ser utilizado no contexto da ESS, pelo que identificamos anecessidade de conceber um DCAP-ESS. Esse desenvolvimento foi efectuado a par da concepçãodo Me4DCAP, como referido, tendo cada um dos trabalhos sido alimentado/influenciado pelooutro.

O Me4DCAP foi validado num grupo de discussão integrado numa conferência da especialidade,e ainda num Focus Group (FG), onde estiveram presentes sete especialistas da comunidademundial de metadados. No final dos nossos trabalhos obtemos como resultados:

• o Me4DCAP V 1.0. A descrição do Me4DCAP é realizada através: (i) da apresentaçãodas actividades que o compõem, e da forma como elas se interligam; (ii) da sugestão detécnicas para realizar as actividades definidas; (iii) da definição do perfil das pessoas quedevem compor a equipe de trabalho do desenvolvimento, e onde elas devem intervir;

• o DCAP-ESS V 1.0, que está vocacionado para servir a comunidade mundial de ESS.

7.2 Principais Contributos

Este projecto de investigação tem vários contributos, em comunidades distintas:1. Na comunidade de WS e de metadados:

• com a definição do Me4DCAP: tanto quanto conseguimos apurar, não existe até aomomento nenhum método para o desenvolvimento de PA ou DCAP. Esperamos que,ao disponibilizarmos uma primeira abordagem a um tal método, aconteçam melhoresprocessos de desenvolvimento de DCAP que desejamos que resultem em melhores



DCAP. Além disso, com a apresentação deste primeira abordagem esperamos criarna comunidade de metadados, um espaço para refexão sobre este tema de forma adesenvolver este campo de investigação, até agora pouco ou nada explorado;

• com o DCAP-ESS: a existência de um novo DCAP é sempre enriquecedor para acomunidade. Foi ainda criado no âmbito deste DCAP-ESS um novo vocabulário enovos esquemas de codificação de vocabulários, todos eles vocacionados para servir aESS, mas que na realidade poderão servir outros contextos de aplicação, de forma aproduzirem descrições mais ricas no que diz respeito à semântica dos termos. O alcanceda utilização do DCAP-ESS, do vocabulário novo e dos novos esquemas de codificaçãode vocabulário é sempre difícil de perspectivar, e só o passar do tempo poderá dar-nosinformação sobre isso. Na realidade o DCAP-ESS por si só não chegará para quese “faça” interoperabilidade. De facto, esta será implementada através da adesão dacomunidade de ESS a este modelo, isto é, através da utilização do DCAP-ESS nosmodelos implementados pelos desenvolvedores de SIW da ESS, de modo a que os SIWque gerem os dados, exponham metadados da WS. O facto deste DCAP-ESS ter sidodesenvolvido em parceria com um grupo da comunidade de ESS é uma mais valia;espera-se que este grupo tenha a capacidade de disseminação do modelo.

• com o processo de desenvolvimento do DCAP-ESS: há na literatura muita informaçãoapresentando DCAP, mas muito poucos relatam a forma como o processo decorreu.Um DCAP é uma ferramenta que é usada por um conjunto de pessoas, comunidadesou organizações que expõem os seus metadados na WS segundo o modelo definido peloDCAP. À partida, é uma incógnita o conhecimento desses utilizadores. O processode desenvolvimento de uma ferramenta que tem à partida como utilizadores umaincógnica é complexo. O espaço de utilização do DCAP é efectivamente um espaçototalmente aberto. O processo de desenvolvimento do DCAP-ESS por nós efectuadopoderá trazer informação a futuros estudiosos desta matéria. Desejamos relatar esteprocesso e desenvolver mais reflexões sobre dele.

2. Na comunidade de ESS: através da utilização do DCAP-ESS na definição dos seus recursos,esta comunidade possui novas possiblidades de funcionamento dos seus SIW:

• passando da dimensão nacional existente neste momento, para a dimensão internacio-nal;

• passando a estar disponíveis para a função de descoberta da WS por parte de SIWfora desta comunidade.

A mudança de paradigma através da exposição dos metadados dos SIW da comunidade deESS poderá provar o potencial da Web Semântica, alimentando a possibilidade de mudançasde comportamento a nível das entidades gestoras de comunidades de ESS no sentido deaderir ao novo paradigma e assim, engrandecer ainda mais a dimensão da comunidade deESS na WS.

3. Na comunidade de DSR em geral e na DSR - Sistemas de Informação em particular: naverdade o que realizámos foi uma instanciação do método dos três ciclos proposto porHevner (2007). Uma vez terminado o nosso processo de DSR, e depois deste ser relatado



na comunidade DSR através de artigo científico publicado em revista da especialidade,desejamos que esta experiência possa enriquecer as reflexões sobre o enquandramentoparticular de Hevner (2007).

7.3 Limitações do estudo

O desenvolvimento do Me4DCAP foi efectuado tendo como suporte uma “situação experimental”Hevner (2007) que se desenrolou no seio apenas da comunidade ESS que, embora sendo mundial,multi-cultural, com diferentes idiomas e multi-aplicacional, não engloba em si mesma todas ascaracterísticas passíveis de serem encontradas noutras comunidades com diferentes graus deheterogeneidade. Não pretendemos, por conseguinte, propôr uma solução universal. Pretendemosantes fornecer um ponto de partida para o estudo e desenvolvimento da problemática “métodospara o desenvolvimento de DCAP” no seio de diferentes comunidades de metadados.

O nosso trabalho parte de uma perspectiva da área da engenharia de software. Respeitamos apossível existência de outras influências num trabalho futuro de melhoramento do nosso trabalho.Isso, a acontecer, viria enriquecer o método.

Na secção 6.3.1 propusemo-nos fazer um estudo que englobasse todos os PA da comunidadede metadados. Sabemos que essa tarefa é uma tarefa complexa e porventura impossível de serconcretizada na sua totalidade. Na realidade tivemos vários tipos de limitações:

1. O facto de não termos conhecimento de todas os idiomas do mundo faz com que os artigose informação existente fora dos idiomas de nosso conhecimento não sejam alcançados;

2. O facto de alguns PA já não estarem a ser utilizados faz com que não haja sítio Webdisponível com informação, nem pessoas de contacto. Alguns PA ainda foram encontradosem artigos científicos, com bastante informação. É impossível obter informaçao sobre osPA que não foram publicados em artigos científicos, agora com os sítios Web em baixo. Éimportante referir que todos os PA nestas condições são do domínio de Learning Objects;pensamos que possivelmente não trariam nada de novo à informação já definida pelorecolhido nos outros PA do mesmo domínio.

3. A dispersão de nomenclatura relativamente ao PA dá lugar a muitas formas de o “dizer”.Este facto dificulta as pesquisas.

4. As novas formas que aparecem de descrição de domínios de conhecimento, que são asgrandes ontologias. Foram encontradas ontologias muito interessantes (exemplo são Breslinet al. (2005), Bojars et al. (2008)) que poderão ter interesse para os trabalhos aqui descritos,mas que de momento ainda não foi possível explorar. Na verdade a sua análise e estudodeverão ser realizados no trabalho futuro. São abordagens diferentes à interoperabilidadeentre as comunidades que será importante integrar no nosso trabalho.

Na secção 2.3 realizamos um estudo para a obtenção do estado da arte dos métodos dedesenvolvimento de PA. Este estudo utilizou diferentes tipos de documentos tais como manuaistécnicos, documentos de projectos, artigos científicos e ainda páginas Web, e ele foi realizadono sentido de procurar métodos para PA dentro de todos, ou de todos os possíveis domíniosidentificados. Relativamente a este estudo dentificamos três limitações:



1. Estando este estudo em parte baseado na pesquisa feita para o estudo sobre PA (estudoreferido no ponto anterior), ele fica contaminado pelas limitações 1, 2 e 3 referidas no pontoanterior.

2. Poderá acontecer que alguns dos PA desenvolvidos tenham utilizado métodos mas quenunca as tenham reportado nem em relatórios técnicos, nem em documentos científicos;

3. Poderá acontecer existirem outros contextos não cobertos pela pesquisa bibliográfica, ondemétodos para desenvolver PA possam estar reportados.

7.4 Trabalho Futuro

Como sabemos um projecto de investigação deverá ser balizado para caber dentro dos limitesimpostos pelo planeamento de tempo. À medida que o trabalho se desenvolve, surgem pistasou ideias que inicialmente não estavam contempladas e que por isso têm de ser deixadas paratrabalho futuro. No momento da escrita deste Tese perspectivamos o seguinte trabalho futuro:

• Perspectivamos a continuação do trabalho de desenvolvimento do DCAP-ESS; há aindaum conjunto de actividades de teste a efectuar, pretendemos:– terminar o processo de desenvolvimento, nomeadamente a realização das actividades

em falta:∗ Definir os Critérios de Adequação;∗ Desenvolver a Validação em Laboratório;∗ Desenvolver a versão final do Description Set Profile (DSP), após a actividade

referida no ponto anterior;∗ Desenvolver os Guias de Utilização;∗ Desenvolver os Guias de Sintaxe.

– assessorar o grupo ESSGlobal na validação em produção do DCAP-ESS, caso osparceiros do projecto estejam interessados. A ESSGlobal decidiu que não iria realizaressa actividade no contexto de desenvolvimento da primeira versão do DCAP-ESS.Mas certamente que após as primeiras experiências de aplicação do DCAP-ESS irãosentir essa necessidade.

• O membro brasileiro da ESSGlobal deseja realizar duas implementações de plug-ins para ex-posição de metadados tendo como base o modelo DCAP-ESS: no Noosfero e no Wordpress1,dois softwares comumente utilizados na comunidade de ESS. Deseja que colaboremos comeles nessa implementação;

• O membro brasileiro da ESSGlobal mostrou interesse no desenvolvimento mais aprofundadodo DCAP-ESS, no sentido de evoluir para uma ontologia para a ESS. Deseja que façamosparte da equipe de trabalho deste novo projecto.

• Perspectivamos a escrita de um conjunto de artigos com o objectivo de partilha do nosso tra-balho com a comunidade científica (a serem publicados em revistas científicas a identificar).Temos em mente os seguintes tópicos para artigos:

1Ver http://noosfero.org/ - acedido em 11 Fevereiro 2014- e https://wordpress.org/ - acedido em 18Abril 2014 - respectivamente.


http://noosfero.org/

https://wordpress.org/


– o processo DSR realizado até ao momento;– a descrição da versão 1.0 do Me4DCAP;– a descrição do processo de desenvolvimento do DCAP-ESS;– a descrição da versão 1.0 do DCAP-ESS. obtidos.

Outros tópicos poderão ser identificados no seguimento do trabalho futuro que aquiperspectivamos.

• Um dos resultados da validação que ficou por explorar foi a possibilidade de integrar afilosofia dos métodos ágeis no Me4DCAP. Projectamos estudar o que possa ter sido já feitonesta área (por exemplo, Ochiai et al. (2014) apresentam um trabalho onde inclui essafilosofia no processo de desenvolvimento de um esquema de metadados), para reflectir edesenvolver versões futuras do Me4DCAP que integrem esta filosofia.

• Perspectivamos a continuação do processo DSR, realizando:– as actividades de field testing da versão 1.0 do Me4DCAP. Queremos abordar a

questão da generalidade do artefacto. O método poderá ser adequado num contextosemelhante ao utilizado por nós na “situação experimental” porque:

∗ foi experimentado à medida que fomos desenvolvendo o DCAP-ESS: na verdadeeste trabalho de “situação experimental” é por si só um processo de validação.Hevner (2007) refere este processo de iteração como um processo que realizamicro-ciclos de avaliação;

∗ porque um grupo de especialistas o validou no FG referido.Se o contexto de aplicação se alterar (um outro contexto de desenvolvimento de umDCAP) ainda menos hipoteses temos neste momento de dizer da sua adequação. Notrabalho futuro projectamos encontrar parceiros que, necessitando de desenvolver umDCAP, queiram usar o Me4DCAP e testá-lo segundo os padrões de avaliação quedefinirmos. Será importante reflectir sobre essas métricas: sendo o nosso artefacto ummétodo, a avaliação de um artefacto intangível não pode fornecer métricas objectivaspara uma avaliação quantitativa, como pode por exemplo um artefacto como umsoftware. Necessitaremos de utilizar abordagens subjectivistas de forma a utilizartécnicas qualitativas. O nosso objectivo será o de compreender quão bem o nossométodo “funciona” March and Smith (1995); uma vez que é um método novo e único -no sentido em que não existe nenhum outro no passado, não é possível utilizar umaabordagem comparativa2. Prevemos:

∗ encontrar técnicas de avaliação utilizadas na área da Engenharia dos Métodos, eadaptar técnica(s) escolhida(s) às nossas necessidades;

∗ desenvolver as métricas apropriadas ao contexto particular em que o método vaiser avaliado.

– as actividades de “teorização” e “justificação” (c.f. Secção 3.2.2.3 e 4.2) de forma acompletar as tarefas do Rigor Cycle DSR. Isso só é possível depois de realizar o fieldtesting referido no ponto anterior.

2Como por exemplo Shovak e Even-Chaime (1987) utilizaram para comparar dois métodos diferentes paraconceber um esquema de base de dados.


Bibliografia

ADULLACT (2004). Profil d’application du LOM pour l’opencartable. http://adullact.net/

docman/?group_id=63&view=listfile&dirid=68. Accessed 15 Jan 2013.

Agostinho, S., Bennett, S., Lockyer, L., and Harper, B. (2004). Developing a learning objectmetadata application profile based on lom suitable for the australian higher education context.Australasian Journal of Educational Technology, 20(2):191–208.

Al-Khalifa, H. S. and Davis, H. C. (n.d.). ARACORE: An arabic learning object metadata forindexing learning resources. n.d.

Allinson, J. and Powell, A. (2006). SWAP application profile. http://www.ukoln.ac.uk/

repositories/digirep/index/Eprints_Application_Profile. Access in 23 Oct 2012.

Australia, E. S. (2011). Metadata Application Profile: ANZ-LOM. http://www.ndrl.edu.au/.Accessed 15 Jan 2013.

Baker, T. and Coyle, K. (2009). Guidelines for dublin core application profiles.http://dublincore.org/documents/profile-guidelines/. Accessed in 26 Jun 2011. Confirmed 19August 2013.

Baker, T. and Coyle, K. (2013). Application profiles as an alternative to owl ontologies. http:

//wiki.dublincore.org/index.php/APvOWL_Lisbon.

Baker, T., Dekkers, M., Heery, R., Patel, M., and Salokhe, G. (2001). What terms does yourmetadata use? application profiles as machine-understandable narratives. Journal of DigitalInformation, 2(2):10.

Baker, T., Nilsson, M., and Johnston, P. (2008). The singapore framework for dublin coreapplication profiles. http://dublincore.org/documents/singapore-framework/. Accessedin 26 Jun 2011. Confirmed 19 August 2013.

Baptista, A. and Machado, A. (2001). Metadata usage in an online journal-an applicationprofile. In Electronic publishing’01: 2001 in the digital publishing odyssey: proceedings of anICCC/IFIP conference held at the University of Kent at Canterbury, Kent, United Kingdom,5-7 July, 2001, page 59. Ios Pr Inc.

233

http://adullact.net/docman/?group_id=63&view=listfile&dirid=68

http://adullact.net/docman/?group_id=63&view=listfile&dirid=68

http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile

http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile

http://www.ndrl.edu.au/

http://wiki.dublincore.org/index.php/APvOWL_Lisbon

http://wiki.dublincore.org/index.php/APvOWL_Lisbon

http://dublincore.org/documents/singapore-framework/

Bibliografia

Baptista, A. A. (2010). A falar nos entendemos - a interoperabilidade entre repositórios digitais.Repositórios institucionais, pages 71–90.

Barker, E. and Ryan, B. (2003). Case studies in implementing educational metadata standards:The higher level skills for industry repository. Technical report, CETIS: the Centre forEducational Technology Interoperability Standards.

Barker, E. and Thomas, A. (2003). Case studies in implementing educational metadata standards:: Ferl—an information service supporting the use of it for teaching and learning. Technicalreport, CETIS: the Centre for Educational Technology Interoperability Standards.

Beck, K. (2005). Extreme Programming Explained: Embrace Change. Addison Wesley, Boston, 2nd edition.

Beck, K., Beedle, M., van Bennekum, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J.,Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber,K., Sutherland, J., and Thomas, D. (2001). Manifesto para o desenvolvimento Ágil de software.http://agilemanifesto.org/iso/ptpt/. Acessed 27 March 2014.

Berners-Lee, T., Hendler, J., Lassila, O., et al. (2001). The semantic web. Scientific American,284(5):34–43.

Boehm, B. (1988). A spiral model of software development and enhancement. Computer,21(5):61–72.

Bohem, B. W. (1976). Software engineering. IEEE trans. Comput., C-25:1126–1241.

Bojars, U., Breslin, J., Peristeras, V., Tummarello, G., and Decker, S. (2008). Interlinking thesocial web with semantics. Intelligent Systems, IEEE, 23(3):29–40.

Borges, P. (2008). Configuração do rup com vista à simplificação dos elencos processuais empmes de desenvolvimento de software. Master’s thesis, University of Minho.

Borges, P., Monteiro, P., and Machado, R. J. (2012). Mapping rup roles to small softwaredevelopment teams. In Software Quality. Process Automation in Software Development, pages59–70. Springer.

Bountouri, L., Papatheodorou, C., Soulikias, V., and Stratis, M. (2009). Metadata interoperabilityin public sector information. Journal of Information Science, 35(2):204–231.

Bourdieu, P. (1980). Le capital social. notes provisoires. In Actes de la recherche en sciencessociales, number 31, pages 2–3.

Boyd, A., Francis, K., Haddaway, E., Perkins, J., Schlosser, M., and Spernoga, M. (2010).Ohiolink digital resources commons (drc) metadata application profile. Technical report,OhioLINK Digital Resources Management Committee (DRMC) Metadata Subcommittee.


http://agilemanifesto.org/iso/ptpt/

Bibliografia

Breslin, J., Harth, A., Bojars, U., and Decker, S. (2005). Towards semantically-interlinked onlinecommunities. The Semantic Web: Research and Applications, pages 71–83.

Brinkkemper, S. (1996). Method engineering: engineering of information systems developmentmethods and tools. Information and software technology, 38(4):275–280.

BSI (2005). BS 8419-1:2005 Interoperability between metadata systems used for learning, educationand training. Code of practice for the development of application profiles. BSI.

Buonazia, I. and Masci, M. (2007). Il PICO application profile. un dublin core application profileper il portale della cultura italiana.

Buonazia, I., Masci, M., and Merlitti, D. (2007). The project of the italian culture portal and itsdevelopment. a case study: Designing a dublin core application profile for interoperability andopen distribution of cultural contents. In Proceedings ELPUB2007 Conference on ElectronicPublishing, Vienna, Austria, giungno, pages 393–404. Citeseer.

C. W-L. LTSO (2012). Cancore metadata - overview. http://www.cen-ltso.net/main.aspx?

put=214&AspxAutoDetectCookieSupport=1. Accessed 15 Jan 2013.

C2S (2009). SCORM. http://www.conform2scorm.com/. Accessed 15 Jan 2013.

Calverley, G. and Johnston, P. (2009). Time-based media application profile: Definition phasereport. Final version: V3.0, JISC.

Carrier, S. (2008). The dryad repository application profile: Process, development, and refinement.Master’s thesis.

Castells, M., Majer, R. V., and Gerhardt, K. B. (2000). A sociedade em rede, volume 3. Paz eterra. São Paulo.

Cattani, A., LAVILLE, J., GAIGER, L., and HESPANHA, P. (2009). Dicionário internacionalda outra economia. Políticas Sociais. Almedina.

Cebeci, Z., Erdogan, Y., and Kara, M. (2008). Traglor: A lom-based digital learning objectsrepository for agriculture. Proc. of the 4th Int. ScientificConference, eLearning and Soft-ware Education.(Ion Roceanu, Ed.),(ISBN: 978-973-749-362-0), University Publishing House,Bucharest, Romania, pages 125–129.

Cecilia, M. O., Muñoz, A., Sanz, M., and Van Assche, F. (2007). Audit report on melt content- version 2 3rd part: Melt application profile. Technical report, Ministerio de Educación yCiencia.

CETIS (2004). The centre for educational technology interoperability standards. http://zope.

cetis.ac.uk/profiles/uklomcore. Accessed 15 Jan 2013.

Chan, L. M. and Zeng, M. L. (2006). Metadata interoperability and standardization: A study ofmethodology part i. D-Lib Magazine, 12(6).


http://www.cen-ltso.net/main.aspx?put=214&AspxAutoDetectCookieSupport=1

http://www.cen-ltso.net/main.aspx?put=214&AspxAutoDetectCookieSupport=1

http://www.conform2scorm.com/

http://zope.cetis.ac.uk/profiles/uklomcore


Bibliografia

Chen, P. (1976). The entity-relationship model—toward a unified view of data. ACM Transactionson Database Systems (TODS), 1(1):9–36.

Chen, Y. and Chen, S. (2005). Metadata lifecycle model and metadata interoperability. In 5thInternational Conference on Conception of Library and Information Science.

Clair, K. (2008). Developing an audiovisual metadata application profile: A case study. LibraryCollections, Acquisitions, and Technical Services, 32(1):53 – 57.

Clayphan, R. and Guenther, R. (2004). Dc-library application profile. http://dublincore.org/

documents/library-application-profile/. Accessed 15 Jan 2013.

Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-WesleyProfessional, Boston.

Comission, N. Z. S. S. (2002). Nzgls metadata element set - version 2.1. Technical report, NewZealand State Services Comission.

Creswell, J. W. (2003). Research design: Qualitative, quantitative, and mixed methods approaches.Sage Publications, Inc., Thousand Oaks, California, USA.

Curado Malta, M. and Baptista, A. (2012a). Social and solidarity economy web informationsystems: State of the art. In Vidal, A. and Torres, T., editors, Social e-Entreprise: ValueCreation through ICT, chapter 1, pages 1–16. IGI Global.

Curado Malta, M. and Baptista, A. (2014). A panoramic view on Metadata Application Profilesof the last decade. International Journal of Metadata, Semantics and Ontologies, 9(1):58–73.

Curado Malta, M., Baptista, A., and Parente, C. (2014). Social and Solidarity Economy WebInformation Systems: State of the Art and an Interoperability Framework. Journal of ElectronicCommerce in Organisations, 12(1):35–52.

Curado Malta, M. and Baptista, A. A. (2012b). State of the art on methodologies for thedevelopment of a metadata application profile. In J. M. Dodero, M. Palomo-Duarte, P. K., editor,Comunications in Computer and Information Sciences, volume 343, page 61–73. Springer-VerlagBerlin Heidelberg.

Curado Malta, M. and Baptista, A. A. (2013a). Me4DCAP V0.1: A method for the developmentof Dublin Core Application Profiles. Journal of Information Systems & Use, 33(2):161–171.

Curado Malta, M. and Baptista, A. A. (2013b). Me4DCAP V0.1: A method to develop DublinCore Application Profiles. In N. Lavesson, P. Linde, P. P., editor, Proceedings of the 17thInternational Conference on Electronic Publishing - Mining the Digital Information Networks,pages 33 – 44. IOS Press.

Curado Malta, M. and Baptista, A. A. (2013c). A method for the development of Dublin CoreApplication Profiles (Me4DCAP V0.2): detailed description. In International Conference onDublin Core and Metadata Applications, pages 90–103. Dublin Core Metadata Initiative.


http://dublincore.org/documents/library-application-profile/


Bibliografia

Curado Malta, M. and Baptista, A. A. (2013d). State of the art on methodologies for thedevelopment of a metadata application profile. International Journal of Metadata, Semanticsand Ontologies, 8(4):332–341.

Currie, M., Geileskey, M., Nevile, L., and Woodman, R. (2002). Visualising interoperability:Arh, aggregation, rationalisation and harmonisation. In Proceedings of the 2002 internationalconference on Dublin core and metadata applications: Metadata for e-communities: supportingdiversity and convergence, pages 177–183. Dublin Core Metadata Initiative.

CWA (2006). Guidelines and support for building application profiles in e-learning (CEN WorkshopAgreement, CWA 15555:2006 E). CEN, European Committee for Standardization, ftp://ftp.

cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/cwa15555-00-2006-Jun.pdf. Accessed in 2 July2012.

da Matta Vegi, L. F. (2012). Technical description - dcap2ap. Technical report, UniversidadeFederal de Viçosa - Centro de Ciências Exatas e Tecnológicas - Departamento de Informática.

da Silva, J. R., Ribeiro, C., and Lopes, J. C. (2012). Semi-automated application profile generationfor research data assets. In Metadata and Semantics Research, pages 98–106. Springer.

Davis, A., Bersoff, E., and Comer, E. (1988). A strategy for comparing alternative softwaredevelopment life cycle models. Software Engineering, IEEE Transactions on, 14(10):1453–1461.

Davis, F. (1985). A technology acceptance model for empirically testing new end-user informationsystems: Theory and results. PhD thesis, Massachusetts Institute of Technology, Sloan Schoolof Management.

DCMI (2010). Dublin core metadata element set, version 1.1. http://dublincore.org/

documents/dces/. Accessed in 26.06.2011.

DCMI (2011). DCMI Glossary. http://wiki.dublincore.org/index.php/Glossary. Accessedin 11 July 2013. Confirmed 19 August 2013.

DCMI (n/d). Dublin core education application profile (working draft of v0.4). https://docs.

google.com/Doc?id=dn8z3gs_38cgwkvv. Accessed in 2 July 2012.

de Almeida, J. and Pinto, J. (1995). A investigação nas ciências sociais. Presença, Lisboa.

de La Passadière, B. and Jarraud, P. (2004). Manuel, a lom application profile forc@mpusciences R©. Sciences et Technologies de l Information et de la Communication pour lÉducation et la Formation, 11.

De Troyer, O. and Leune, C. (1998). Wsdm: a user centered design method for web sites.Computer Networks and ISDN Systems, 30(1):85–94.

DRIVER (2011). Digital Repository Infrastructure Vision for European Research. http:

//www.driver-repository.eu/. Accessed 15 Jan 2013.


ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/cwa15555-00-2006-Jun.pdf

ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/cwa15555-00-2006-Jun.pdf

http://dublincore.org/documents/dces/


http://wiki.dublincore.org/index.php/Glossary

https://docs.google.com/Doc?id=dn8z3gs_38cgwkvv

https://docs.google.com/Doc?id=dn8z3gs_38cgwkvv

http://www.driver-repository.eu/

http://www.driver-repository.eu/

Bibliografia

DSDM Consortium (2013). Dynamic systems development method. http://www.dsdm.org.

Dublin Core Collections Task Group (2007). Dublin core collections application profile. http://

dublincore.org/groups/collections/collection-application-profile/. Accessed 15Jan 2013.

Dublin Core Government Task Group (n/d). DC-Gov application profile. http://dublincore.

org/groups/government/profile-200111.shtml. Accessed 15 jan 2013.

Duval, E., Hodgins, W., Sutton, S., and Weibel, S. (2002). Metadata principles and practicalities.D-lib Magazine, 8(4):16.

Eadie, M. (2008). Towards an application profile for images. Ariadne, 55.

education.au (2006). Edna resources - metadata application profile.

EESV, P. E. S. (2012). Process and methodology for core vocabularies. Technical report,Interoperability solutions for European Public Administrators.

Evers, A. and Laville, J.-L., editors (2004). The Third Sector in Europe. Globalization andWelfare. Edward Elgar Publishing Limited.

FAO (n/d). Guidelines for exchanging event metadata: The Ag-Event Application Profile.Technical report, Food and Agriculture Organisation of the United Nations.

FAO (n/d). Guidelines for exchanging job vacancy metadata: the Ag-Job Application Profile.Technical report, Food and Agriculture Organisation of the United Nations.

FBES and de l’Economie Social, C. (2008). Ousar solidariedade: partilhas e práticas de economiasocial e solidária no Brasil e no Quebec. Forum Brasileiro de Economia Solidária - Chantierde l’Economie Social.

Feliciati, P. (2010). Towards a sound management of digital culture. metadata schemes andapplication profiles for digital repositories. In Proceedings of the 2nd International SymposiumDigitization of Cultural Heritage of Bosnia and Herzegovina, pages 134–138, Sarajevo (BosniaHervegovina). Faculty of Electrical Engineering Sarajevo.

Fernández-López, M., Gómez-Pérez, A., and Juristo, N. (1997). Methontology: from ontologicalart towards ontological engineering.

Fisheries, F. and Aquaculture Department (2011). Fisheries metadata element set - FiMES.http://www.fao.org/fishery/topic/166231/en. Accessed in 4 Juin 2012.

Fontes, B. (2008). Capital social e terceiro setor: sobre a estruturação das redes sociais emassociações voluntárias. MARTINS, PH, FONTES, BASM Redes sociais e saúde: novaspossibilidades teóricas. 2a ed. Recife: Editora Universitária, pages 49–75.


http://www.dsdm.org

http://dublincore.org/groups/collections/collection-application-profile/

http://dublincore.org/groups/collections/collection-application-profile/

http://dublincore.org/groups/government/profile-200111.shtml

http://dublincore.org/groups/government/profile-200111.shtml

http://www.fao.org/fishery/topic/166231/en

Bibliografia

Fowler, M. (2004). UML distilled - A Brief Guide to the Standard Object Modeling Language.Addison-Wesley Professional, Boston, 3rd edition.

Framework, A. F. (2007). Vet metadata application profile (vetadata). Technical report,Australian Flexible Framework.

Friesen, N., Mason, J., and Ward, N. (2002). Building educational metadata application profiles.In Proceedings of the International Conference on Dublin Core and Metadata for e-Communities,volume 2002, pages 63–69.

Galliers, R. D. and Land, F. F. (1987). Viewpoint: choosing appropriate information systemsresearch methodologies. Communications of the ACM, 30(11):901–902.

Garzotto, F., Mainetti, L., and Paolini, P. (1993). Navigation patterns in hypermedia databases.In System Sciences, 1993, Proceeding of the Twenty-Sixth Hawaii International Conference on,volume 3, pages 370–379. IEEE.

George, Y., Akli, L., Chang, A., Collins, C., Gull, K., Gough, N., Lowy, M., Matyas, M.,Muramatsu, B., Musante, S., and Taylor, J. (2011). Ben (bioscieducation network) meta-data specification - version 1.3.1. Technical report, AAAS for the Bioscieducation NetworkCollaborative 2002.

Godby, C. (2004). What do application profiles reveal about the Learning Object Metadatastandard. Ariadne, 41.

Gómez-Pérez, A., Fernández, M., and De Vicente, A. (1996). Towards a method to conceptualizedomain ontologies. In Wahlster, W., editor, Proceedings of the 12th European Conferenceon Artificial Intelligence, pages 41–51, Budapeste. European Coordinating Committee forArtificial Intelligence (ECCAI).

Government of Ontario (2005). Web Metadata Standard - Government of Ontario IT Standards(GO-ITS) - Document No. 43. Technical report, Ministru of Government Services.

Greenberg, J., White, H., Carrier, S., and Scherle, R. (2009). A metadata best practice for ascientific data repository. Journal of Library Metadata, 9(3-4):194–212.

Gregor, S. and Hevner, A. (2013). Positioning and presenting design science research for maximumimpact. MIS Quarterly, pages 337–356.

Gregor, S. and Jones, D. (2007). The anatomy of a design theory. Journal of the Association forInformation Systems, 8(5):312–335.

Group, D. C. C. D. T. (2007). Asset description metadata schema. http://joinup.ec.europa.

eu/asset/adms/release/100. Accessed 15 Jan 2013.

Halpin, T. (2006). Handbook on Architectures of Information Systems, chapter Object-rolemodeling (ORM/NIAM), pages 81–103. International Handbooks on Information Systems.Springer.


http://joinup.ec.europa.eu/asset/adms/release/100

http://joinup.ec.europa.eu/asset/adms/release/100

Bibliografia

Halpin, T. and Morgan, T. (2008). Information modeling and relational databases. MorganKaufmann, Burlington, MA, USA, second edition.

Haslhofer, B. and Isaac, A. (2011). data. europeana. eu: The europeana linked open data pilot.In International Conference on Dublin Core and Metadata Applications, pages 94–104.

Heery, R. and Patel, M. (2000). Application profiles: mixing and matching metadata schemas.Ariadne, 25:27–31.

Hennicker, R. and Koch, N. (2000). A UML-based methodology for hypermedia design. «UML»2000—The Unified Modeling Language, pages 410–424.

Hesse, W. (2003). Dinosaur meets archaeopteryx? or: Is there an alternative for rational’s unifiedprocess? Software and Systems Modeling, 2(4):240–247.

Hevner, A. (2007). The three cycle view of design science research. Scandinavian Journal ofInformation Systems, 19(2):87.

Hevner, A. and Chatterjee, S. (2010). Design Research in Information Systems - Theory andPractice, volume 22 of Integrated Series in Information Systems. Springer.

Hevner, A., March, S., Park, J., and Ram, S. (2004). Design science in information systemsresearch. MIS quarterly, 28(1):75–105.

Highsmith, J. (2004). Agile Project Management: Creating Innovative Products. Addison-Wesley.ISBN: 0-321-21977-5.

ICTU: E-Overheid voor Burgers (2011). Normatieve specificatie OWMS 4.0 - overheid.nl web me-tadata standaard. Technical report, Ministerie van Binnenlandse Zaken en Koninkrijksrelaties.

IDABC (2004). interoperability for european egovernment services. http://ec.europa.eu/

idabc/en/document/5313/5883.html. Accessed in 10.10.2011.

IEEE (2010). Standards glossary. http://www.ieee.org/education_careers/education/

standards/standards_glossary.html. Accessed in 23.11.2011.

Iglesias, C. A., Garijo, M., Molina, D., and de Juan, P. (2009). VMAP. A Dublin Core ApplicationProfile for Musical Resources. In Fabio Satori, Miguel A. Sicilia, N. M., editor, Metadata andSemantic Research: Third International Conference, MTSR 2009, number 46 in CCIS, pages1–12. MTSR, Springer Verlag.

IMS Global Learning Consortium, Inc. (2005a). IMS Application Profile Guidelines: Part 1 -Management Overview. IMS Global Learning Consortium, Inc., version 1 edition.

IMS Global Learning Consortium, Inc. (2005b). IMS Application Profile Guidelines: Part 2 -Technical Manual. IMS Global Learning Consortium, Inc., version 1.0 edition.


http://ec.europa.eu/idabc/en/document/5313/5883.html

http://ec.europa.eu/idabc/en/document/5313/5883.html

http://www.ieee.org/education_careers/education/standards/standards_glossary.html

http://www.ieee.org/education_careers/education/standards/standards_glossary.html

Bibliografia

INE (2013). Conta satélite da economia social 2010. Technical report, INE, Lisbon, Portugal.ISBN: 978-989-25-0196-3.

Isakowitz, T., Stohr, E., and Balasubramanian, P. (1995). RMM: a methodology for structuredhypermedia design. Communications of the ACM, 38(8):34–44.

IT-Research, N. N. (2012). Norsk LOM-profil – NORMLOM. http://www.itu.no/filestore/

NSSL/NORLOM/NORLOM_v1_0.pdf. Accessed 15 Jan 2013.

Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process,volume 1. Addison Wesley, Boston, MA, USA.

Johnston, P. (2006). Michael-eu Dublin Core application profile. http://www.ukoln.ac.uk/

metadata/michael/michael-eu/dcap/. Accessed 15 Jan 2013.

Kemman, M. (2009). MPEG21 DIDL application profile for institutional reposi-tories. http://wiki.surf.nl/display/standards/MPEG21+DIDL+Application+Profile+

for+Institutional+Repositories. Accessed 13 Jan 2013.

Khazraee, E. and Park, J. (2010). Lessons learned from eiah metadata application profile (emap).Cataloging & Classification Quarterly, 48(5):472–485.

Kroll, P. and Kruchten, P. (2003). The rational unified process made easy: a practitioner’s guideto the RUP. Addison-Wesley Professional, Boston, MA, USA.

Kruchten, P. (2004). The rational unified process: an introduction. Addison-Wesley Professional,Boston, MA, USA, 3 edition.

Krueger, R. A. and Casey, M. A. (2000). Focus Groups: A Practical Guide for Applied Researc.Thousand Oaks, CA. Sage Publications, 3 rd edition.

Larman, C. (2004). Agile and iterative development: a manager’s guide. Addison-WesleyProfessional, USA.

Laville, J.-L. (2009). L’Économie solidaire dans le débat théorique. Revista Acessa, (1). Açores.

Lechat, N. (2007). Economia social, economia solidária, terceiro setor: do que se trata? Civitas-Revista de Ciências Sociais, 2(1).

Lee, H., Lee, C., and Yoo, C. (1999). A scenario-based object-oriented hypermedia designmethodology. Information & Management, 36(3):121–138.

Lister, K. (2008). Toward Semantic Interoperability for Software Systems. PhD thesis, Universityof Melbourne, Dept. of Computer Science and Software Engineering.

LOREnet (2010). LORE LOM. http://wiki.surf.nl/display/standards/LORElom. Accessed15 Jan 2013.


http://www.itu.no/filestore/NSSL/NORLOM/NORLOM_v1_0.pdf

http://www.itu.no/filestore/NSSL/NORLOM/NORLOM_v1_0.pdf

http://www.ukoln.ac.uk/metadata/michael/michael-eu/dcap/


http://wiki.surf.nl/display/standards/MPEG21+DIDL+Application+Profile+for+Institutional+Repositories

http://wiki.surf.nl/display/standards/MPEG21+DIDL+Application+Profile+for+Institutional+Repositories

http://wiki.surf.nl/display/standards/LORElom

Bibliografia

Lourdi, I. and Papatheodorou, C. (2004). A metadata application profile for collection-leveldescription of digital folklore resources. In Database and Expert Systems Applications, 2004.Proceedings. 15th International Workshop on, pages 90–94. IEEE.

Lynch, C. A. (1997). The z39.50 information retrieval standard - part i: A strategic view of itspast, present and future. D-Lib Magazine.

Manouselis, N. and Costopoulou, C. (2006). A metadata model for e-markets. InternationalJournal of Metadata, Semantics and Ontologies, 1(2):141–153.

Manouselis, N., Kastrantas, K., and Tzikopoulos, A. (2007). An ieee lom application profile todescribe training resources for agricultural & rural smes. In Proc. of the 2nd InternationalConference on Metadata and Semantics Research (MTSR’07), Corfu, Greece. Citeseer.

Manouselis, N., Najjar, J., Kastrantas, K., Salokhe, G., Stracke, C., and Duval, E. (2010).Metadata interoperability in agricultural learning repositories: an analysis. Computers andElectronics in Agriculture, 70(2):302–320.

Manouselis, N., Salokhe, G., and Keizer, J. (2009). Comparing different metadata applicationprofiles for agricultural learning repositories. Metadata and Semantics, pages 469–479.

March, S. and Smith, G. (1995). Design and natural science research on information technology.Decision support systems, 15(4):251–266.

Marzal García-Quismondo, M., Calzada Prado, J., and Cuevas Cerveró, A. (2006). Desarrollo deun esquema de metadatos para la descripción de recursos educativos: el perfil de aplicaciónmimeta. Revista española de documentación científica, 29(4):551–571.

Massart, D. and Shulman, E. (2011). Learning resource exchange metadata application profileversion 4.7. Technical report, European Schoolnet.

McCracken, D. and Jackson, M. (1982). Life cycle concept considered harmful. ACM SIGSOFTSoftware Engineering Notes, 7(2):29–32.

Moen, W., Huang, J., and McCotter, M. (2010). Extraction and parsing of herbarium specimendata: Exploring the use of the dublin core application profile framework. In Proceedings ofIConference 2010, pages 154 – 160. University of Illinois at Urbana-Champaign.

Moura, A., Pereira, G., and Campos, M. (2002). A metadata approach to manage and organizeelectronic documents and collections on the web. Journal of the Brazilian Computer Society,8(1):16–31.

Myers, M. D. (1997). Qualitative research in information systems. Management InformationSystems Quarterly, 21:241–242.

Nagamori, M. and Sugimoto, S. (2006). A metadata schema registry as a tool to enhancemetadata interoperability. TCDL Bulletin, 3(1).


Bibliografia

National Archives of Australia (2010). AGLS metadata standard - part ii - usage guide. Technicalreport, National Archives of Australia.

Nevile, L. and Lissonnet, S. (2005). Was cimi too early? dublin core and museum information:metadata as cultural heritage data. In International Conference on Dublin Core and MetadataApplications, page 31.

Nijssen, G. and Halpin, T. (1989). Conceptual Schema and Relational Database Design: a factoriented approach. Prentice Hall.

Nikos, M. and Axel, M. (2010). Application profiles for describing cerorganic. Technical report,Mediterranean Agronomic Institute of Chania.

Nilsson, M. (2008). Description set profiles: A constraint language for dublin core application pro-files. http://dublincore.org/documents/2008/03/31/dc-dsp/. This is a DCMI WorkingDraft. Accessed in 4th April 2014.

Nilsson, M., Baker, T., and Johnston, P. (2009). Interoperability levels for dublin core metadata.http://dublincore.org/documents/interoperability-levels/. Accessed in 26 June 2011.Confirmed 19 August 2013.

NISO Framework Working Group (2007). A Framework of Guidance for Building Good DigitalCollections. NISO, 3 rd edition.

Niso Press (2004). Understanding metadata. NISO Press Booklets, US, ISBN, 1:880124–62.

Normetic (n/d). Normetic. http://www.normetic.org/Nouvel-article.html. Accessed 15Jan 2013.

OAI (2008). Open archives intiative - object reuse and exchange. http://www.openarchives.

org/ore/. Accessed 14 jan 2013.

Ochiai, K., Nagamori, M., and Sugimoto, S. (2014). A metadata schema design model andsupport system based on an agile development model. In Proceedings of the InternationalConference IConference 2014, pages 921–927. iSchools.

Onyancha, I., Keizer, J., and Katz, S. (2001). A dublin core application profile in the agriculturaldomain. In International Conference on Dublin Core and Metadata Applications, number 0,pages pp–185.

Palavitsinis, N., Kastrantas, K., and Manouselis, N. (2009a). Interoperable metadata for afederation of learning repositories on organic agriculture and agroecology. In Proc. of JointInternational Agricultural Conference (JIAC2009), Wageningen, Netherlands, accepted forpublication.

Palavitsinis, N., Manouselis, N., and Sanchez Alonso, S. (2009b). Evaluation of a metadataapplication profile for learning resources on organic agriculture. Metadata and SemanticResearch, pages 270–281.


http://dublincore.org/documents/2008/03/31/dc-dsp/

http://dublincore.org/documents/interoperability-levels/

http://www.normetic.org/Nouvel-article.html

http://www.openarchives.org/ore/


Bibliografia

Parliment, E. (2009). European parliament resolution of 19 february 2009 on so-cial economy. http://www.europarl.europa.eu/sides/getDoc.do?type=TA&reference=

P6-TA-2009-0062&language=EN&ring=A6-2009-0015. Accessed in 13 February 2011.

Patra, C. (2009). Application profile for ceramic resources. http://metadataregistry.org/

schema/show/id/19.html. Accessed 15 Jan 2013.

Payette, S., Blanchi, C., Lagoze, C., and Overly, E. (1999). Interoperability for digital objectsand repositories. D-Lib Magazine, 5(5):1082–9873.

Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chatterjee, S. (2007). A design scienceresearch methodology for information systems research. Journal of management informationsystems, 24(3):45–77.

Powell, A. (2009). RDN/LTSN LOM application profile. http://www.intute.ac.uk/

publications/rdn-ltsn/ap/. Acedido em 3 de Junho de 2012.

Powell, A., Nilsson, M., Naeve, A., Baker, T., and Johnston, P. (2007). DCMI abstractmodel. http://dublincore.org/documents/2007/06/04/abstract-model/. Accessed in26.06.2011.

Purao, S. (2002). Design research in the technology of information systems: Truth or dare.online], Pennsylvania State University, http://purao. ist. psu. edu/working-papers/dare-purao.pdf.

Purao, S. (2013). Truth or dare: The ontology question in design science research. Journal ofDatabase Management, 24(3):51–66.

Rodriguez Artacho, M., Colin, J.-N., Ilomäki, L., Jaakkola, T., Lakkala, M., Lehtinen, E., Nurmi,S., Paavola, S., Panzavolta, S., Robinson, M., Roozen, F., Sanz, M., j., S., and Trigar, M.(2003). The celebrate metadata application profile. Technical report, Celebrate.

Rossi, M. and Sein, M. K. (2003). Design research workshop: a proactive research approach.Presentation delivered at IRIS, 26:9–12.

Royce, W. (1970). Managing the development of large software systems. In proceedings of IEEEWESCON, volume 26. Los Angeles.

Ruddy, D. (2010). Developing a metadata exchange format for mathematical literature. Towardsa Digital Mathematics Library, pages 27–36.

Rühle, S., Baker, T., and Johnston, P. (2011). User guide - DCMI. http://wiki.dublincore.

org/index.php/User_Guide. Accessed in 25.11.2011.

Rumbaugh, J. and Blaha, M. (2004). Object-oriented modeling and design. Prentice Hall, Inc.


http://www.europarl.europa.eu/sides/getDoc.do?type=TA&reference=P6-TA-2009-0062&language=EN&ring=A6-2009-0015

http://www.europarl.europa.eu/sides/getDoc.do?type=TA&reference=P6-TA-2009-0062&language=EN&ring=A6-2009-0015

http://metadataregistry.org/schema/show/id/19.html


http://www.intute.ac.uk/publications/rdn-ltsn/ap/



http://wiki.dublincore.org/index.php/User_Guide

http://wiki.dublincore.org/index.php/User_Guide

Bibliografia

Rushing, A., Koenig, J., Mitchell, A., Moen, W., Strawn, T., and Thomale, J. (2008). Texasdigital library descriptive metadata guidelines for electronic theses and dissertations, version1.0. Prepared for and published by the Texas Digital Library.

Salokhe, G., Pesce, V., and Liesthout, J. (2008). Organization metadata application profile.Technical report, FAO.

Scherer-Warren, I. (2006). Das mobilizações às redes de movimentos sociais. Sociedade e Estado,21(1):109–130.

Schiochet, V. (2009). Institucionalização das políticas públicas de economia solidária: brevetrajetória e desafios. mercado de trabalho, 40:55.

Schneider, G. and Winters, J. (2001). Applying use cases: a practical guide. Addison-Wesley,Upper Saddle Rive, NJ, USA, second edition.

Scholl, H. (2005). Interoperability in e-government: More than just smart middleware.

ScoLOMFR (2011). Schema de description des ressources num eriques de l’enseignement scolaire.http://www.lom-fr.fr/scolomfr. Accessed 15 Jan 2013.

Semanticweb.org (2012). Semantic web. http://www.semanticweb.org. Accessed in 14.01.2012.Verified in 3.03.2014.

Shadbolt, N., Hall, W., and Berners-Lee, T. (2006). The semantic web revisited. IntelligentSystems, IEEE, 21(3):96 –101.

Shoval, P. and Even-Chaime, M. (1987). Database schema design: an experimental comparisonbetween normalization and information analysis. ACM SIGMIS Database, 18(3):30–39.

Simon, H. A. (1996). The sciences of the artificial. MIT press, Cambridge, Massachusetts, thirdedition.

Singer, P. (2008). Economia solidária. Estudos Avançados, 22(62):287.

Singer, P. and Schiochet, V. (2006). Atlas da economia solidaria no brasil 2005. SENAES/MTEBrasil, page 60.

Slater, J. (2001). Guidelines for FAILTE metadata. Technical report, Facilitating Access toInformation on Learning Technology for Engineers.

Stuempel, H., Salokhe, G., Aubert, A., Keizer, J., Nadeau, A., Katz, S., and Rudgard, S. (2009).Metadata application profile for agricultural learning resources. Metadata and Semantics,pages 499–507.

Takahashi, K. and Liang, E. (1997). Analysis and design of web-based information systems.Computer Networks and ISDN Systems, 29(8):1167–1180.


http://www.lom-fr.fr/scolomfr

http://www.semanticweb.org

Bibliografia

Takeda, H., Veerkamp, P., and Yoshikawa, H. (1990). Modeling design process. AI magazine,11(4):37.

Team, S. R. (2002). Renardus - the academic subject gateway service in europe. http://

renardus.sub.uni-goettingen.de/renap/. Accessed 15 Jan 2013.

Tolvanen, J. (1998). Incremental method engineering with modeling tools: theoretical principlesand empirical evidence. University of Jyväskylä.

Tremblay, M., Hevner, A., and Berndt, D. (2010). The use of focus groups in design scienceresearch. Design Research in Information Systems, pages 121–143.

UK-online (2008). e-government metadata standard. Technical report, Cabinet Office - Office ofthe e-Envoy.

US National Library of Medecine (2004). National library of medecine metadata set. http:

//www.nlm.nih.gov/tsd/cataloging/metafilenew.html. Accessed 14 Jan 2013.

Vaishnavi, V. and Kuechler, B. (2012). Design science research in information systems. http:

//desrist.org/design-research-in-information-systems/. Accessed in 25 April 2013.

Vicente, A. (1997). Conceptualizacion de verbos en ontologías de dominio. Master’s thesis,Facultad de Informatica. Universidad Politécnica de Madrid.

W3C (2010). RDF - W3C standards. http://www.w3.org/RDF/. Acessed in 14 Jan 2012.Confirmed 9 Feb 2013.

W3C (2012a). The semantic web vocabularies. http://www.w3.org/standards/semanticweb/

ontology. Accessed 10 September 2012.

W3C (2012b). W3C semantic web activity. http://www.w3.org/2001/sw/. Accessed 30 Jul2012.

Ward, N. (2003). Creating a metadata application profile: A case study of the learning federationexperience. In Proceedings of the EDUCAUSE in Australasia 2003 Conference, pages 6–9.

Wijers, G. M. (1991). Modelling support in Information Systems development. PhD thesis,Technische Universeit Delft.

Wilson, K., Billington, L., Moir, S., and Carpenter, S. (2007). Development of a metadataapplication profile at the state library of new south wales. Library Papers, page 4.

Yang, H. and Tang, J. (2003). A three-stage model of requirements elicitation for web-basedinformation systems. Industrial Management & Data Systems, 103(6):398–409.

Zschocke, T., Beniest, J., Paisley, C., and Najjar, J. (2009). The lom application profile foragricultural learning resources of the cgiar. International Journal of Metadata, Semantics andOntologies, 4(1):13–23.


http://renardus.sub.uni-goettingen.de/renap/


http://www.nlm.nih.gov/tsd/cataloging/metafilenew.html


http://desrist.org/design-research-in-information-systems/

http://desrist.org/design-research-in-information-systems/

http://www.w3.org/RDF/

http://www.w3.org/standards/semanticweb/ontology

http://www.w3.org/standards/semanticweb/ontology

http://www.w3.org/2001/sw/

Apêndice A

Análise preliminar dos Sistemas deInformação Web da Economia Sociale SolidáriaApresentamos no quadro resumo a análise realizada aos SIW selecccionados na primeira partedo estudo do estado da arte. Esta análise está organizada por continente.

Este estudo foi realizado entre Janeiro e Março de 2011.

247

REAS URL Temáticas RSSTAG

Sim/Não Sim/Não Níveis Sim/Não Quais

Europa

Áustria

Sim Não --- Sim Sim Sim Sim Não Não Não Sim Infinito Sim

Espanha

Não Não --- Não Não Sim Sim Sim Não Não Sim 1 Sim

França

Não Não --- Sim Não Não Não Não Não Não Não Não

Sim Sim Não Sim Sim Sim Sim Não Sim Não Sim

Itália

Não Não --- Sim Sim Sim Sim Sim Sim Sim Sim 1 Sim

Sim Sim Sim Não Não Não Não Não Não Não Sim

Luxemburgo

Não Não --- Sim Não Sim Sim Não Não Não Não --- Sim

América Latina

Brasil

Sim Não --- Sim Sim Sim Sim Sim Sim Não Sim 1 Sim

Sim Sim Não Não Não Sim Não Sim Não Não --- --- ---

Catálogo produtos

Venda onlineMapping News Events Blog

Rede Social

Metadados

Obs.

http://vivirbien.economiasolidaria.org Técnico: http-equiv; charset

http://economiasolidaria.org Técnico: http-equiv; charset

http://www.la-bdis.org n/d Técnico: http-equiv; charset; robots

Semântico: description

http://eco-sapiens.com Labels especiais n/d

Técnico: http-equiv; charset

Semântico: description; keywords

http://www.zoes.it Técnico: http-equiv; charset

http://www.buonmercato.org Preço Transparente n/d Técnico: http-equiv;

charset

Semântico:description; keywords

http://www.ecolux.lu Técnico: http-equiv; charset; generator

Semântico: language

http://cirandas.net Técnico: http-equiv; charset

Semântico: description

http://www.solidarius.com.br Moeda própria

Chile

Sim Não --- Não Não Sim Sim Não Não Não Não --- Sim

Peru

Não Não --- Não Não Sim Não Não Não Não Não --- Sim

Uruguai

Sim Não --- Não Não Sim Não Não Não Não Não --- Sim

América do Norte

Canadá*

Sim Sim Não Não Não Não Não Não Não Não --- Sim

Sim Não --- Sim Não Sim Sim Não Não Não Não --- Sim

Ásia

Não Não --- Não Não Sim Não Sim Não Não Não --- Não

Áfricasem representação na Internet

* Os dois SIW do Canadá usam a mesma base de dados

http://redeconomiasolidaria.com Técnico: http-equiv; charset; generator; robots

Semântico: tile; description; author; keywords

http://gresp.org.peTécnico: http-equiv; charset

http://www.comerciojustouruguay.com Técnico: generator

http://www.achetersolidaire.com

Banca de pedidos; banca de ofertas

Técnico: http-equiv; charset; robots


http://www.economiesolicalequebec.caTécnico: http-equiv; charset; robots


http://aa4se.com **

** Trata-se de um sítio Web implementado com o software WordPress

A. Análise preliminar dos Sistemas de Informação Web da Economia Social e Solidária


Apêndice B

Relato dos trabalhos com o grupo daEconomia Social e SolidáriaB.1 Fase 1 - estudo do contexto, problematização

O consórcio-Réseaux Intercontinental de Promotion de l’Économie Social Solidaire (RIPESS)decidiu, como um primeiro passo, trabalhar no desenvolvimento de vocabulários controlados.Entendeu também que necessitava de dar os mesmos nomes às mesmas ”coisas“, algo que nãoacontecia ainda. Além disso, o consórcio necessitava de encontrar um entendimento comum dasemântica. Estas conclusões foram encontradas após duas reuniões:

• a primeira em Paris, em Fevereiro 2011, com um grupo de líderes de ESS de 6 países (Brasil,Canada, Espanha, França, Itália, Luxemburgo) e ainda dois especialistas informáticos.Neste encontro havia claramente o desejo profundo de encontrar entendimentos que oslevassem a colocar os seus SIW a partilhar informação no futuro. Não entanto não era nadaclaro como fazê-lo: a reunião foi um debate animado, de certa forma caótico-democrático,onde os membros do consórcio tentaram encontrar um primeiro entendimento das ”coisas“que queriam partilhar, enumerando-as e categorizando-as (ver Secção B.1.1).

• a segunda no forum internacional de economia social e solidária, em 20111, em Montreal noCanadá, onde finalmente um primeiro objectivo foi definido: o desenvolvimento de listascontroladas de termos. Estas listas são: actividades (nível 1), temas, produtos e serviçose qualificadores. Nesta segunda reunião, o consórcio definiu também outra informaçãoque deseja partilhar: promotores de ESS, centros de investigação de políticas públicasem ESS, mapeamento e validação de métodos, inteligência económica. Como vai ser estapartilha efectuada ainda não é claro para o consórcio. Mas foi definida uma declaração deintenções. Parece ser assunto para ser definido também, a nosso ver, ao nível dos esquemasde metadados.

Após esta reunião do Canadá, foram programadas uma série de reuniões seguintes. Elasforam realizadas utilizando o software Skype, devido às distâncias geográficas.

As duas reuniões seguintes foram totalmente centradas no desenvolvimento das listas con-troladas de termos. Um conjunto de documentos com uma proposta rascunho das 4 listas de

12011 International Forum for the Social and Solidarity Economy (FIESS)

251

B. Relato dos trabalhos com o grupo da Economia Social e Solidária

termos foi enviado antes da reunião, através da mailing list do consórcio. Estes rascunhos foramelaborados pelo parceiro Brasileiro.

Na terceira reunião, em Dezembro de 2011, o consórcio aprovou um primeiro nível dalista Actividades. Um segundo nível será elaborado no futuro, de momento é ainda dificilencontrar consensos. Foi ainda aprovada a lista Temas assim como um segundo rascunho da listaQualificadores.

Na quarta reunião, em Janeiro de 2012, a lista Qualificadores foi aprovada e o rascunho dosProdutos e Serviços definido. Esta última lista controlada de termos é a mais complexa umavez que tem centenas de termos e muitos deles dependentes da cultura, da região e do contexto.Passamos a descrever o processo de discussão que aconteceu: o consórcio começou a discussão àvolta das duas listas, de produtos e serviços, já existentes:

• o United Nations Statistics Division Central Production of Classification (CPC)2;

• o United Nations Standard Products and Services Code (UNSPSC)3.

A metodologia usada foi: a partir de um dos vocabulários encontrar uma base de trabalhopara depois o modificar de forma a encontrar as particularidades da ESS. Para isso, o parceiroBrasileiro disponibilizou uma página Web com vários exemplos possíveis4 onde várias bases detrabalho foram construídas com duas mudanças essenciais:

• diferentes versões com diferentes níveis de definição, no que diz respeito a categorias esub-categorias;

• diferentes versões com items que foram retirados da lista (por exemplo categorias quetivessem a ver com guerra - armamento).

Com esta página Web o consórcio podia ver as diferentes versões simplesmente clicando numacaixa de combinação. O consórcio decidiu pela UNSPSC (até ao segundo nível), com algumascategorias retiradas.

Nesta quarta reunião o consórcio decidiu que as listas seriam multi-idioma: inglês, francês,espanhol, português e italiano.

O consórcio-RIPESS tem outras perspectivas de listas controladas de termos para desenvolver,sobretudo depois dos trabalhos relatados na Fase 2 (ver Secção B.2).

A Tabela B.1 apresenta um resumo das listas controladas de termos desenvolvidas. Umresumo das conclusões e resultados de cada reunião pode ser encontrado na Tabela B.2.

B.1.1 Resultados reunião de Paris

Na reunião de Paris, que aconteceu a 26 de Março de 2011, estiveram presentes os representatesdo consórcio RIPESS para o desenvolvimento de interoperabilidade entre os WIS RIPESS. Os

2http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=16 - acedido em 27 de Março 2012.3http://www.unspsc.org/ - acedido em 27 de Março 2012.4Ver http://www.fbes.org.br/progs/scripts/produtos-servicos-essglobal/selects.html - acedido em

28 de Março 2012.


http://www.fbes.org.br/progs/scripts/produtos-servicos-essglobal/selects.html


participantes identificaram pontos essenciais de entendimento comum para partilha de informações.De seguida é apresentada uma síntese da reunião.

Ponto 1 - Dados a partilhar entre SIWDados “iniciativa”

1. Fichas sinaléticas + dados geográficos: a) Classificação jurídica, b) Imagem, missão, etc, c)Envolvimentos valores acrescentados (social, ambiente, etc);

2. Classificação de actividade;3. Produtos e Serviços;4. Adesão a redes / outras relações;5. Filiére (fornecedores, compradores) ou cooperação (projectos, parceiros, necessidades,

redes);6. Organização do trabalho (por exemplo: % de trabalhadores);7. Certificação / garantias;8. Objectivo;9. Transparência e relatório;

10. Competências – mutualismo, saber fazer, recursos.Ficou claro que há países que não possuem ainda estes dados todos sobre as organizações deESS existentes nos seus SIW. Ficou também claro que há muita informação que precisa de sertratada e conceitos esclarecidos. Por essa razão, encontrou-se na reuinão um ponto comum deentendimento para começar a trabalhar:

• Actividade• Serviço/Produtos• Critério de economia solidária• Temas de economia solidária (notícias, acontecimentos, ofertas de trabalho)

Ponto 2 - Implementar uma SIW globalEsta plataforma Web deverá estar a funcionar com o mínimo de informação em Outubro de 2011por alturas do Forum Mundial de ESS que irá realizar-se no Canadá. O objectivo da plataformaexperimental é o de desenvolver alguma interoperabilidade entre as plataformas existentes, deforma a mostrar as potencialidades.

Tabela B.1: Listas controladas de termos definidas pelo consórcio.

Nome O quêActividades Sector de actividade (Level 2).Qualificadores Qualificadores para produtos e serviços ou para actividades.Produtos e Serviços Para comercialização de produtos e serviços de ESS.Temas Meta temas para catalogar documentos, grupos de discussão

(forum on-line, mailing lists) ou outros.


B.R

elatodos

trabalhoscom

ogrupo

daEconom

iaSociale

SolidáriaTabela B.2: Reuniões consórcio-Réseaux Intercontinental de Promotion de l´Economie Sociale Solidaire e resultados.

Data Resultados Onde ObservaçõesFev2011

Criação de um consórcio para o de-senvolvimento de interoperabilidadeentre os SIW da ESS. Criação deuma mailing list.

Paris Primeiro encontro com o objectivo de en-contrar formas de desenvolver interopera-bilidade entre os SIW da ESS. Brainstor-ming, reunião caótico-democrática Presen-tes 6 líderes da ESS representando Brasil,Canadá, Espanha, França, Itália e Luxem-burgo; 2 especialistas informáticos (Françae Luxemburgo).

Out2011

Definido o objectivo de desenvolvi-mento de listas controladas de ter-mos ver Tabela B.1.

FIESS 2011,Montreal,Canadá.

Stand na feira. Apresentação de projectosna feira como parte do programa da feira.Novos contactos estabelecidos com novospaíses. Presentes 5 líderes da ESS repre-sentando o Brasil, Canadá, Espanha, Itáliae Luxemburgo.

Dez2011

Aprovada a lista controlada de ter-mos “actividades” (nível 1) e “te-mas”, e definido um rascunho para“qualificadores”.

Skype Estados Unidos da América pela primeiravez numa reunião do consórcio. Presentes5 líderes da ESS representando Brasil, Ca-nadá, EUA, França e Itália; 2 especialistasinformáticos (França e Canadá).

Jan2012

Aprovada a lista controlada de ter-mos “qualificadores”. Aprovado orascunho da lista controlada de ter-mos “Produtos e Serviços”. Multi--idioma para todos as listas contro-ladas de termos: espanhol, inglês,italiano, francês e português.

Skype A lista controlada de termos ”Produtose Serviços“ foi desenvolvida a partir deuma lista modificada do código United Na-tions Standard Products and Services Codehttp://www.unsps.org. Presentes 5 líde-res da ESS representando Brasil, Canadá,EUA, França e Itália; 2 especialistas infor-máticos (França e Canadá)

254Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica


A tecnologia WS foi apresentada por um convidado programador que trabalha para uma redelocal de ESS em França, e que está no momento da reunião a construir um SIW de ESS parauma região em França. Este convidado apresentou as suas dificuldades em descrever os recursose suas propriedades, pela sua particularidade.

Ponto 3 – Criação do consórcioEste consórcio terá como participantes as plataformas nacionais presentes na reunião. Tem comoobjectivo principal a criação de uma plataforma ESSGlobal para mostrar as possibilidades dainteroperabilidade entre SIW da ESS. Esta plataforma reunirá todas as informações que asplataformas nacionais disponibilizarem através de tecnologia WS. Durante a reunião foi desen-volvido uma pequena montra em linha disponível em http://www.fbes.org.br/essglobal/5

que nos apresenta alguns dados a nível do planeta. Esta ferramenta não está desenvolvida comtecnologia de WS, é somente uma recolha de dados através do acesso directo às bases de dadosdos parceiros.

B.1.2 Resumo das entrevistas a líderes da Econoia Social e Solidária

Na tabela B.3 é apresentado um resumo das conclusões e reflexões retiradas das entrevistas aoslíderes mundias deESS.

5Acedido em Junho 2011.


http://www.fbes.org.br/essglobal/

B.R

elatodos

trabalhoscom

ogrupo

daEconom

iaSociale

SolidáriaTabela B.3: Conclusões das entrevistas exploratórias Réseaux Intercontinental de Promotion de l’Économie Social Solidaire.

# Conclusões Observações1 A comunidade ESS deseja partilhar a informação

que está nos seus SIW.

2 a) Grandes diferenças nas organizações de ESS O projecto de investigação deverá definir claramente quais as organizações que estão“dentro“ e “fora” do projecto.

b) Difícil encontrar entendimentos a) É muito difícil encontrar entendimentos nas abordagens comuns.1) para a informação a ser partilhada 2) para a semântica da informação a serpartilhada.b) É muito dificil chegar a entendimentos em vocabulários comuns;c) Como consequência dos dois pontos anteriores pensamos ser necessáriodesenvolver num plano de aceitação por parte da comunidade de ESS deforma a envolver o mais intensamente possível esta comunidade no processo dedesenvolvimento da solução de implementação de interoperabilidade, de formaa suavizar o impacto que essa solução possa ter. Caso contrário poderá seruma solução não aceite/não usada pela comunidade de ESS.

3

Informação a ser partilhada:a) Workflow do processo de admissão para sermembro de um SIW.b) Produtos e Serviços para um futuro mercadoESS-B2C e ESS-B2B (e-shop e e-marketplace,respectivamente)c) Actividades por tópico.

4 A comunidade de ESS não quer ficar dentro dasua galaxia. Tem como intensão abrir portas aoutro tipo de SIW, seja governamental seja decomércio electrónico da economia de mercado

Estudar com mais pormenor as possíveis entidades/organizações que possamestar interessadas em receber informação da comunidade de ESS.

256Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica


B.1.3 Guião das entrevistas líderes da Economia Social e Solidária

Na página seguinte apresentamos o guião que foi enviado aos participantes das entrevistas.


Mariana Malta | University of Minho | RIPESS's Interview Script

Goal of the Interviews

To understand the needs for interoperability of the ESS community and of their technological

platforms

Script

1. What is the name of your Organization and in which country is it based?

2. What is the mission/goal of your Organization?

3. What is your role in your Organization?

4. What is the web platform of your Organization, if it does not have one, is there any that

you are using?

5. What are the Organizations/individuals that can login in your platform?

6. What are the interactions they can have in your platform? Can you describe them in detail?

7. Can you provide me the the data model?

8. Does the platform has any kind of interaction (e.g. data exchange) with other plataforms?

Can you identify them? Can you tell which data you change and with what

Organizations/Individuals? What are the technologies used?

9. (“No” to question 8) Do you whish the platform to have any kind of interaction with other

platforms? Which ones? Can you describe how you envision this interactions? In the case

you have already thought about it, what technology, what type of sintaxe scheme or

vocabulary schemes you would like to use to implement it?

10. (“Yes” to question 8) Would you like to have more interactions with other type of platforms

(e.g. e-governement, e-commerce, others)? Can you explain how? Which data? Do you

have any data model for that? Any vocabulary schemes?

11.Do you know any software aiming the ESS and if so, do you know if they implement

interoperability. If so at what level?

12. (“Yes” to question 11) can you provide me the name of the platform and contacts?

13.Whould you be interested in participating in a International Project of R&D with the goal of

studying, propose and implement semantic interoperability solutions to those platforms

and, if so, what is the role you or someone in your Organization could have in this project?

.

14.Do you have anything to add to what we have said?

15.Can I contact you in the future for future developments?

21st March 2011

Mariana Malta – University of Minho – RIPESS's interview script


B.2 Fase 2 - Desenvolvimento do Dublin Core Application Pro-file-Economia Social e Solidária

Nesta secção descrevemos o trabalho realizado em cada reunião da “situação experimental”;descrevemos os pontos principais de desenvolvimento e acrescentamos os comentários críticosaos trabalhos realizados, que foram servindo de input no trabalho paralelo de construção doMe4DCAP.

B.2.0.1 1a Reunião

Data: 23 de Outubro de 2012Presenças: Daniel Tygel, Alan Tygel, Jason Nardi, Craig Borowiak.

Estratégia Me4DCAP:Definição da equipe e do plano de trabalho. Contextualização do processo.Assuntos tratados:

• Foi apresentado o contexto teórico do Enquadramento de Singapura e quais os passos quetinhamos de percorrer para definir o DCAP. Era importante fazer esta contextualizaçãoporque nenhum dos elementos do grupo conhecia as especificidades do Enquadramento deSingapura, nem entendia os conceitos subjacentes à aplicação de um DCAP;

• Ficou decidido que na reunião seguinte apresentaríamos um plano de trabalho (Work Plan)para o grupo entender a dimensão do projecto e organizar o trabalho;

• O grupo informou que havia um estudo feito por alguns dos seus elementos sobre asvárias bases de dados que suportam os SIW da ESS, onde estão identificadas as tabelas erespectivos campos de cada uma das base de dados. Decidiu-se que este documento iria serpartilhado por todos, e comentou-se que poderia servir de ajuda/suporte à identificaçãodos termos de metadados necessários para o DCAP-ESS.

Artefactos em desenvolvimento: Plano de Trabalho.Comentários:

• Identificamos a importância de introduzir no método a possibilidade de utilizar modelos dedados já existentes (que suportam bases de dados existentes) nas organizações ou qualquerdocumento das organizações com informação que pudesse ajudar a definir o modelo dedados;

• No caso presente, por se tratarem de várias organizações em várias localizações do mundo,a possibilidade de análise de documental era uma questão complexa;

• Identificamos a problemática de ser um ambiente demasiado heterogéneo e aberto, istoporque o DCAP-ESS irá servir não só as organizações do consórcio, como muitas outrasno mundo inteiro, muitas delas até desconhecidas - não é possível prever quem irá utilizaro DCAP-ESS. Perguntamo-nos se isto é um problema particular ao caso do DCAP-ESSou subjacente a todas as construções de DCAP.



B.2.0.2 2a Reunião

Data: 6 de Novembro de 2012Presenças: Daniel Tygel, Alan Tygel, Jason Nardi, Craig Borowiak.

Estratégia Me4DCAP:• Propomos que o processo comece com o desenvolvimento de um “Plano de Trabalho” e

um “Documento Visão”. Estes dois documentos devem ser os primeiros a ser desenvolvidos;após a sua conclusão, o desenvolvimento de outros artefactos se seguirá;

• É necessário desenvolver um “Glossário”, no entanto é um documento que pode (e deve)ser desenvolvido ao longo do processo.

Assuntos tratados:• Apresentação e discussão do Plano de Trabalho;• O primeiro passo a ser realizado é o de definição de Requisitos Funcionais (ComponentStage 1 ). Para isso definimos no Me4DCAP a necessidade de construir Casos-de-uso(Use Cases);

• Foi necessário apresentar o conceito de caso-de-uso: uma técnica para identificar requisitosfuncionais;

• Começamos por descrever os Casos com uma frase, de forma a ter ideia do que precisamosfazer (Use-Cases High Level);

• Cada membro ficou responsável por pensar nos casos-de-uso que achasse pertinentes. Nestafase não foi definido nenhum modelo para a elaboração dos casos, cada membro faria umadescrição em texto corrido do seu caso;

• Foi apresentada, por parte do líder do grupo, a necessidade de realizar um documentode texto com a Visão do projecto e um outro documento com o Glossário (Glossary).Estes documentos irão ser desenvolvidos no Wiki, o primeiro nos tempos mais próximos,o segundo ao longo do projecto. O líder do grupo ficou responsável por organizar o Wikie por introduzir estes dois textos, Visão e Glossário, com as primeiras ideias e termos,respectivamente. Todos ficaram de participar, ao longo do projecto, na concepção doGlossário.

Artefactos em desenvolvimento: Definir os Requisitos de Alto-nível; Modelo de Casos-de-Uso;Visão; Glossário;Comentários:Apesar de ainda não termos terminado a elaboração da Visão, o grupo quis avançar de imediatopara a elaboração de algo concreto. Propusemos a elaboração dos Casos-de-uso.

B.2.0.3 3a reunião

Data: 4 de Dezembro de 2012Presenças: Daniel Tygel, Alan Tygel, Jason Nardi, Craig Borowiak.

Estratégia Me4DCAP:



Toda a equipe de trabalho envolvida na elaboração dos Casos-de-Uso.Assuntos tratados:

• O plano de trabalho foi revisto e reformulado;• Foram apresentadas 5 Descrições dos Casos-de-Uso. Alguns membros da equipa apresenta-ram textos com as descrições. Foram discutidos os casos-de-uso.

• Para uniformizar o trabalho, o líder do grupo ficou de disponibilizar um modelo de textopara apresentar os Casos-de-Uso na Dropbox. Cada membro iria desenvolver o seu Caso eregistá-lo no modelo disponibilizado, colocando os ficheiros na Dropbox. O líder do grupoficou responsável de os organizar posteriormente no Wiki, quando terminados;

• a necessidade de ter um modelo para o preenchimento dos casos mostrou ser uma maisvalia. Tal recurso ajuda sobretudo para pessoas com perfil não técnico.

Artefactos em desenvolvimento: Modelo Casos-de-Uso; Visão; Glossário.

Comentários:O desenvolvimento dos Casos-de-Uso deverá ser elaborado pelos elementos da equipe de trabalhoque conhecem o domínio de aplicação; deverão ser, no entanto, assessorados por elementos comcompetências de análise de sistemas.

B.2.0.4 4a reunião

Data: 8 de Janeiro de 2013Presenças: Daniel Tygel, Alan Tygel, Jason Nardi, Craig Borowiak.

Estratégia Me4DCAP:Toda a equipe de trabalho deve estar envolvida na elaboração dos Casos-de-Uso, que começama tomar forma. O trabalho seguinte será o de elaborar o Diagrama UML de casos-de-uso paracompletar o Modelo de Casos-de-uso de forma a poderem ser desenvolvidos os Requisitos Funcio-nais. Estes dois artefactos podem ser elaborados pelos elementos do grupo de trabalho de perfilmais técnico.Assuntos tratados:

• O plano de trabalho foi revisto e reformulado;• Foi discutido o documento Visão. Daniel Tygel ficou responsável por desenvolver estedocumento por não ter concordado com o que foi escrito pelo líder do grupo;

• Os Casos-de-uso foram discutidos ao pormenor, e melhorados. Dois dos Casos-de-Uso, porfalta de tempo, ficaram para ser discutidos na reunião seguinte;

• O líder do grupo propõe-se: realizar o diagrama UML de Casos-de-Uso e iniciar a elaboraçãodos Requisitos Funcionais a partir dos casos.

Artefactos em desenvolvimento: Descrição pormenorizada dos Casos-de-Uso; DiagramaUML de Casos-de-Uso; Visão; Glossário; Requisitos FuncionaisComentários:

• O Documento Visão é um documento que deve ser assumido pela equipe de trabalho: o facto



de um membro (elemento com perfil especialista de domínio de aplicação e notoriamentelíder do grupo) não ter gostado da formulação do Documento Visão realizado pelo líder dogrupo de trabalho (com perfil tecnológico) é a prova disso;

• Identificamos a necessidade absolutamente obrigatória de ter um elemento no grupo comconhecimentos de conceitos de modelação semântica. Verificámos que os dois elementoscom um perfil de analista de sistemas tinham forte experiência de desenvolvimento deprojectos em bases de dados relacionais; o seu raciocínio teve de ser guiado e adaptado ànova realidade.

B.2.0.5 5a reunião

Data: 18 de Janeiro de 2013Presenças: Daniel Tygel, Alan Tygel, Jason Nardi, Craig Borowiak.

Estratégia Me4DCAP: Nada a acrescentar. Ainda a elaboração dos Descrição pormeno-rizada dos Casos-de-Uso.Assuntos tratados: Discussão dos dois casos restantes deixados da última reunião. Estes casoscaem porque não estão dentro do âmbito do projecto.Artefactos em desenvolvimento: Descrição pormenorizada dos Casos-de-Uso; DiagramaUML de Casos-de-Uso; Documento Visão; Glossário; Requisitos FuncionaisComentários:Os dois casos eliminados do processo não tinham pertinência no contexto global de partilhade metadados mas sim num contexto particular de transferências de dados entre um cliente eum servidor de base de dados. Mais uma vez se vê que os analistas de sistemas não tinhamconhecimentos de WS querendo impôr os conceitos dos modelos relacionais e tecnologias de basede dados.

B.2.0.6 6a reunião

Data: 5 de Fevereiro de 2013Presenças: Daniel Tygel, Alan Tygel, Jason Nardi, Craig Borowiak.

Estratégia Me4DCAP:Uma vez definidos os Requisitos Funcionais passa-se à elaboração do Modelo de Domínio (Com-ponent Stage 2 ). Propomos a utilização da técnica Unified Model Language (UML) para orepresentar.Assuntos tratados:

• O plano de trabalho foi re-estruturado;• Foi discutido o documento Visão. Daniel Tygel ficou responsável por desenvolver estedocumento;

• Foram discutidos em pormenor os Casos-de-Uso. Entra-se no pormenor da nomenclaturade determinados termos. Antevê-se a necessidade de definir mais vocabulários controlados



e a necessidade de construir consensos uma vez que se verifica existirem diferentes conceitospara os mesmos nomes.

Artefactos em desenvolvimento: Visão; Glossário; Casos-de-Uso; Requisitos Funcionais;Modelo de Domínio.Comentários:

• É nosso entendimento de que o Documento Visão já deveria estar fechado. No entantoa equipe de trabalho não investe tempo neste documento. Prefere investir o tempo dareunião nos Casos-de-Uso;

• Embora estivesse na agenda da reunião, voltou-se a não discutir o documento que define osRequisitos Funcionais e que tinha sido preparado pelo líder do grupo para ser discutido nareunião; verifica-se que há uma grande tendência dos membros da equipe com competênciasem análise de sistemas de saltar etapas. Desejo de passar de imediato dos Casos-de-Usopara o Modelo de Domínio.

• O Modelo de Domínio começa a tomar forma, apesar de não ser utilizado nenhuma técnicavisual nem ter sido definido que o iriamos elaborar na reunião.

B.2.0.7 7a reunião

Data: 19 de Fevereiro de 2013Presenças: Daniel Tygel, Alan Tygel, Jason Nardi.

Estratégia Me4DCAP: Elaboração do Modelo de Domínio a partir dos Casos-de-Uso e dosRequisitos Funcionais. Propomos a utilização da técnica UML.Assuntos tratados:

• O plano de trabalho foi revisto e reformulado;• Discussão do Diagrama UML representando o Modelo de Domínio (diagrama elaboradopelo líder do grupo);

• Depois da discussão, o líder do grupo de trabalho ficou responsável pela correcção doModelo de Domínio e de o actualizar no Wiki.

Artefactos em desenvolvimento: Modelo de DomínioComentários:

• Um rascunho do Modelo de Domínio foi elaborado por nós, e posto à discussão perante oselementos com perfil de especialidade de domínio de aplicação;

• Foi utilizada a técnica UML por ser a técnica utilizada pelo Guia da DCMI e pelo DCAPSWAP. No entanto, esta ou qualquer outra técnica poderia ter sido usada porque oselementos do grupo que não tinham perfil técnico não entenderam a representação deimediato, foi necessário fazer uma explicação prévia. Achamos muito interessante a técnicaObject Role Modeling (ORM), porque se aproxima muito da lógica da modelação de dadospara a codificação posterior em DSP ou RDF; desta forma facilitaria a passagem para acodificação. Decidimos que esta técnica seria a utilizada no Modelo Detalhado de Dados.



B.2.0.8 8a reunião

Data: 7 de Março de 2013Presenças: Alan Tygel.

Estratégia Me4DCAP:Aprofundamento do Modelo de Domínio com as propriedades de cada objecto. Modelo de dadosdetalhado utilizando a técnica ORM.Assuntos tratados:

• Discussão do Modelo de Dados detalhado - Técnica ORM;• Depois da discussão, o líder do grupo de trabalho ficou responsável pela correcção dodiagrama ORM e de o actualizar no Wiki.

Artefactos em desenvolvimento: Modelo de Dados DetalhadoComentários:Só analistas de sistemas estiveram na discussão. Diagrama ORM final será apresentado à equipealargada.

B.2.0.9 9a reunião

Data: 9 de Abril de 2013Presenças: Craig Borowiak.

Estratégia Me4DCAP:Início da elaboração do Guia de Utilização.Assuntos tratados:

• Discussão do Diagrama ORM;• O líder do grupo, com o perfil mais técnico, irá corrigir o Modelo de Domínio apresentado

e de o aprofundar depois da discussão;• Elementos do grupo especialistas no domínio de aplicação responsáveis por alimentar oWiki com as descrições de cada objecto do domínio e propriedades de cada objecto.

Artefactos em desenvolvimento: Modelo de Dados Detalhado - ORM; Guia de Utilização.Comentários:Um membro da equipe com perfil Especialista de Domínio reviu o modelo e deu feedback parareformulação.

B.2.0.10 10a reunião

Data: 5 de Fevereiro de 2014Presenças: Daniel Tygel.

Estratégia Me4DCAP:Validação do Modelo de Dados Detalhado.Assuntos tratados:



• Discussão do Diagrama ORM;• Correcção de relações e de entidades do diagrama ORM;• Correcção de descrição de termos.

Artefactos em desenvolvimento: Modelo de Dados Detalhado; Guias de Utilização.Comentários:Modelo de dados validado pelo membro da equipe com perfil duplo: Analista de Sistemas eEspecialista de Domínio.


Apêndice C

Análise dos Perfis de Aplicação demetadadosNeste apêndice apresentamos os resultados pormenorizados do estudo da secção 6.3.1 - Estadoda Arte dos Perfis de Aplicação.

C.1 Lista dos Perfis de Aplicação de metadados analisados pordomínio de aplicação

Na Tabela C.1 apresentamos em detalhe os PA encontrados no estudo.

Agricultura

Acrónimo Enq. Singapura ReferênciaAno: 2005AGRIS Não Onyancha et al. (2001)Ano: 2008Organization AP Não Salokhe et al. (2008)Ano: 2011FiMES Não Fisheries and Aquaculture Department (2011)Ano: n/aAg-Event AP Não FAO (nd)Ag-Job AP Não FAO (nd)

Bibliotecas/Repositórios

Acrónimo Enq. Singapura ReferênciaAno: 2002RENAP Não Team (2002)Ano: 2004DC-LIB Não Clayphan and Guenther (2004)NLM MS Não US National Library of Medecine (2004)

Continua na página seguinte...

267

C. Análise dos Perfis de Aplicação de metadados

Tabela C.1: Continuação da página anterior

Acrónimo Enq. Singapura ReferênciaAno: 2006Michael-eu DCAP Não Johnston (2006)Ano: 2007DC-CDAP Não Dublin Core Collections Task Group (2007)MAP Não Wilson et al. (2007)Ano: 2008OAI-DC Não DRIVER (2011)TDL ETD MOS Não Rushing et al. (2008)Ano: 2009MPEG-21 DIDL Não Kemman (2009)Ano: 2010DRC AP Não Boyd et al. (2010)

Ciência

Acrónimo Enq. Singapura ReferênciaAno: 2006SWAP Sim Allinson and Powell (2006)Ano: 2010APIARY AP Não Moen et al. (2010)DRYAD Sim Greenberg et al. (2009)

MLAP Não Ruddy (2010)

E-Government

Acrónimo Enq. Singapura ReferênciaAno: 2005GO-WMES Não Government of Ontario (2005)Ano: 2006DC-Gov Não Dublin Core Government Task Group (nd)Ano: 2008e-GMS Não UK-online (2008)PSI AP Não Bountouri et al. (2009)Ano: 2010OWMS Não ICTU: E-Overheid voor Burgers (2011)Ano: 2012ADMS Não Group (2007)

Multi-Domínio

Acrónimo Enq. Singapura ReferênciaAno: 2002





Acrónimo Enq. Singapura ReferênciaNZGLS Não Comission (2002)Ano: 2006DC-EM AP Não Manouselis and Costopoulou (2006)Ano: 2008Audovisual AP Não Clair (2008)Ano: 2009TBM-AP Sim Calverley and Johnston (2009)VMAP Sim Iglesias et al. (2009)

Ano: 2010AGLS MS Não National Archives of Australia (2010)

Objectos de Aprendizagem

Acrónimo Enq. Singapura ReferênciaAno: 2002ANZ LOM Não Australia (2011)FAILTE Não Slater (2001)Ano: 2003Celebrate AP Não Rodriguez Artacho et al. (2003)CanCore AP Não C. W-L. LTSO (2012)FERL Não Barker and Thomas (2003)HLSI Não Barker and Ryan (2003)Ano: 2004LOMAP Não Agostinho et al. (2004)ManUel Não de La Passadière and Jarraud (2004)OpenCartable Não ADULLACT (2004)UK LOM Core Não CETIS (2004)SCORM Não C2S (2009)Ano: 2005Ag-LR Não Stuempel et al. (2009)AraCore Não Al-Khalifa and Davis (nd)NORMLOM Não IT-Research (2012)TLF AP Não Ward (2003)Ano: 2006MIMETA Não Marzal García-Quismondo et al. (2006)Edna Não education.au (2006)Ano: 2007DC-Edu Não DCMI (nd)





Acrónimo Enq. Singapura ReferênciaVedata Não Framework (2007)MELT Não Cecilia et al. (2007)ReGov Não Manouselis et al. (2007)Ano: 2008Normetic Não Normetic (nd)Ano: 2009Organic Edu.net Não Palavitsinis et al. (2009a)CG LOM Não Zschocke et al. (2009)RLLOMAP Não Powell (2009)Ano: 2010CerOrganic AP Não Nikos and Axel (2010)LORELOM Não LOREnet (2010)scoLOMFR Não ScoLOMFR (2011)Ano: 2011LREAP Não Massart and Shulman (2011)BEN Não George et al. (2011)

Património Cultural

Acrónimo Enq. Singapura ReferênciaAno: 2001MAG Não Feliciati (2010)Ano: 2004QuinkMap Não Nevile and Lissonnet (2005)Folklore Descrip-tion AP

Não Lourdi and Papatheodorou (2004)

Ano: 2007PICO Não Buonazia et al. (2007)Ano: 2010EMAP Não Khazraee and Park (2010)Ano: 2012ESE Não Haslhofer and Isaac (2011)EDM Não Haslhofer and Isaac (2011)

Outros

Acrónimo Enq. Singapura ReferênciaAno: 2001IOAP Não Baptista and Machado (2001)Ano: 2008





Acrónimo Enq. Singapura ReferênciaOAI-ORE Não OAI (2008)Ano: 2009CRAP Não Patra (2009)Ano: 2010IAP Sim Eadie (2008)Ano: 2012DC2AP Não da Matta Vegi (2012)

Tabela C.1: Perfis de aplicação de metadados analisados

C.2 Perfis de Aplicação de metadados analisados - Linha dotempo

Na Figura C.1 é apresentado um gráfico de uma dimensão. A unidade do eixo é o ano; iniciando-seem 2001 e terminando em 2012. Nesta linha são colocados os PA estudados no ano correspondenteà sua produção, por área de aplicação. Cada área (identificada em Inglês) tem uma côr, comoindica a legenda da figura. Os PA sem referência à data de criação são colocados no final dalinha, junto à referência “n/a”. A esta linha demos o nome de linha do tempo dos PA estudados.

Esta linha do tempo foi elaborada pela aluna de mestrado Taciana Isabel Azevedo dos Santos,no âmbito da UC “Iniciação à Investigação em TSI” do Mestrado de Sistemas de Informação doDepartamento de Sistemas de Informação da Escola de Engenharia da Universidade do Minho.Este trabalho foi realizado numa fase posterior à publicação do artigo baseado neste estudo - c.f.Curado Malta and Baptista (2014) - entre Novembro e Dezembro de 2013.



Figura C.1: A linha do tempo dos Perfis de Aplicação de metadados estudados



C.3 Matriz I - Perfis de Aplicação de metadados analisados

A tabela C.2 apresenta a listagem categoria-tabela resumo de PA.

Tabela C.2: Categorização dos Perfis de Aplicação de metadados

Domínio TabelaAgricultura C.3Ciência C.20E-Government C.25Multi-domínio C.32Objectos de Aprendizagem C.39Património Cultural C.70Outros C.78

C.3.0.11 Domínio: Agricultura

Tabela C.3: Lista dos Perfis de Aplicação Analisados no domínio da Agricultura

AgriculturaAcrónimo Nome Tabela Enq. SingapuraAno: 2005AGRIS AGRIS Network C.4 NãoAno: 2008Organization AP Organization Application Profile C.5 NãoAno: 2011FiMES Fisheries Metadata Element Set C.6 NãoAno: n/aAg-Event AP Agricuture Events Application Profile C.7 NãoAg-Job AP Agricultura Jobs Application Profile C.8 Não



Tabela C.4: Perfil de Aplicação de metadados AGRIS

Acrónimo AGRIS APAno 2005Nome AGRIS NetworkTipo de Instituição Organização InternacionalDomínio AgriculturaSub-Domínio Information ManagementVersão V1.1Singapura 0Baseado em dc, dcterms, agmesNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.fao.org/docrep/008/ae909e/ae909e00.htmURI n/a

Tabela C.5: Perfil de Aplicação de metadados Organization AP

Acrónimo Organization APAno 2008Nome Organization Application ProfileTipo de Instituição Organisação/Empresa InternacionalDomínio AgriculturaSub-Domínio —-Versão n/aSingapuraBaseado em dc, agmesNovos termos 0Binding XMLMetodologia 1FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL ftp://ftp.fao.org/gi/gil/gilws/aims/metadata/

docs/organizationap.pdfURI n/a


http://www.fao.org/docrep/008/ae909e/ae909e00.htm

ftp://ftp.fao.org/gi/gil/gilws/aims/metadata/docs/organizationap.pdf

ftp://ftp.fao.org/gi/gil/gilws/aims/metadata/docs/organizationap.pdf


Tabela C.6: Perfil de Aplicação de metadados FiMES

Acrónimo FiMESAno 2011Nome Fisheries Metadata Element SetTipo de Instituição Organisação/Empresa InternacionalDomínio AgriculturaSub-Domínio FicheriesVersão n/aSingapura 0Baseado em n/aNovos termos n/aBinding XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.fao.org/fishery/topic/166231/enURI n/a

Tabela C.7: Perfil de Aplicação de metadados Ag-Event

Acrónimo Ag-Event APAno n/aNome Agricuture Events Application ProfileTipo de Instituição Organisação/Empresa InternacionalDomínio AgriculturaSub-Domínio eventsVersão n/aSingapura 0Baseado em dc, RSS 1.1, agmesNovos termos 1Binding XMLMetodologia 0FR 1DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL ftp://ftp.fao.org/docrep/fao/010/ai255e/ai255e00.

pdfURI n/a


http://www.fao.org/fishery/topic/166231/en

ftp://ftp.fao.org/docrep/fao/010/ai255e/ai255e00.pdf

ftp://ftp.fao.org/docrep/fao/010/ai255e/ai255e00.pdf


Tabela C.8: Perfil de Aplicação de metadados Ag-Job AP

Acrónimo ag-job-APAno n/aNome Agricultura Jobs Application ProfileTipo de Instituição Organisação/Empresa InternacionalDomínio AgriculturaSub-Domínio jobsVersão n/aSingapura 0Baseado em Dcterms, RSS1.1, agmesNovos termos 1Binding XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://aims.fao.org/sites/default/files/

uploadsfiles/ag-job-AP.pdfURI n/a


http://aims.fao.org/sites/default/files/uploadsfiles/ag-job-AP.pdf

http://aims.fao.org/sites/default/files/uploadsfiles/ag-job-AP.pdf


C.3.0.12 Domínio: Bibliotecas/Repositórios

Tabela C.9: Lista dos Perfil de Aplicação de metadados de metadados no domínio das Bibliote-cas/Repositórios

Bibliotecas/RepositóriosAcrónimo Nome Tabela SingapuraAno: 2002RENAP Renardus Application Profile C.10 NãoAno: 2004DC-LIB Dublin Core Library Application

ProfileC.11 Não

NLM MS NLM Metadata Schema C.12 NãoAno: 2006Michael-eu Michael-eu DCAP C.13 NãoAno: 2007DC-CDAP Dublin Core Collections Description

Application ProfileC.14 Sim

MAP State Library of New South WalesMetadata Application Profile

C.15 Não

Ano: 2008OAI-DC OAI-DC C.16 NãoTDL ETD MODS Texas Diligital Library Electronic Te-

sis DissertationC.17 Não

Ano: 2009MPEG-21 DIDL MPEG21 DIDL Application Profile

for Institutional RepositoriesC.18 Não

Ano: 2010DRC AP Digital Resources Commons Appli-

cation ProfileC.19 Não



Tabela C.10: Perfil de Aplicação de metadados RENAP

Acrónimo RENAPAno 2002Nome Renardus Application ProfileTipo de Instituição Comunidade CientíficaDomínio Bibliotecas/RepositóriosSub-Domínio Academic Subject GatewayVersão DraftSingapura 0Baseado em dc,dcterms, rmes, rmesqNovos termos 1Binding n/aMetodologia 0FR 1DM 1DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://renardus.sub.uni-goettingen.de/renap/URI n/a

Tabela C.11: Perfil de Aplicação de metadados DC-LIB

Acrónimo DC-LIBAno 2004Nome Dublin Core Library Application ProfileTipo de Instituição Organização InternacionalDomínio Bibliotecas/RepositóriosSub-Domínio —Versão draft versionSingapura 0Baseado em dcterms, modsNovos termos 0Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://dublincore.org/documents/

library-application-profile/URI n/a






Tabela C.12: Perfil de Aplicação de metadados NLM MS

Acrónimo NLM MSAno 2004Nome NLM Metadata SchemaTipo de Instituição Organisação/Empresa NacionalDomínio Bibliotecas/RepositóriosSub-Domínio MedicineVersão n/dSingapura 0Baseado em dcNovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://www.nlm.nih.gov/tsd/cataloging/metafilenew.

htmlURI n/d

Tabela C.13: Perfil de Aplicação de metadados Michael-eu DCAP

Acrónimo Michael-euAno 2006Nome Michael-eu DCAPTipo de Instituição Comunidade CientíficaDomínio Bibliotecas/RepositóriosSub-Domínio —-Versão DraftSingapura 0Baseado em dc,dcterms, MARC, rslp, michaelNovos termos 1Binding n/aMetodologia 0FR 0DM 1DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://www.ukoln.ac.uk/metadata/michael/

michael-eu/dcap/URI n/a







Tabela C.14: Perfil de Aplicação de metadados DC-CDAP

Acrónimo DC-CDAPAno 2007Nome Dublin Core Collections Description Application ProfileTipo de Instituição Organização/Empresa InternacionalDomínio Bibliotecas/RepositóriosSub-Domínio —-Versão n/aSingapura 0Baseado em dc, dcterms, cld, marcrelNovos termos 0Binding 0Metodologia 0FR 1DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://dublincore.org/groups/collections/

collection-application-profileURI n/a

Tabela C.15: Perfil de Aplicação de metadados MAP

Acrónimo MAPAno 2007Nome State Library of New South Wales Metadata Application

ProfileTipo de Instituição Organização/Empresa RegionalDomínio Bibliotecas/RepositóriosSub-Domínio Objectos Digitais, Conteúdo Web, Conteúdos de ArquivosVersão V2.3Singapura 0Baseado em Dc, METS, MODS,MIX, TextMD, METSRighs, aglsNovos termos 0Binding 0Metodologia 1FR 1DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a


http://dublincore.org/groups/collections/collection-application-profile

http://dublincore.org/groups/collections/collection-application-profile


Tabela C.16: Perfil de Aplicação de metadados OAI-DC

Acrónimo OAI-DCAno 2008Nome OAI-DCTipo de Instituição Comunidade CientíficaDomínio Bibliotecas/RepositóriosSub-Domínio Comunicação CientíficaVersão 2.0Singapura 0Baseado em dcNovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.driver-support.eu/URI n/d

Tabela C.17: Perfil de Aplicação de metadados TDL ETD MODS

Acrónimo TDL ETD MODSAno 2008Nome Texas Diligital Library Electronic Tesis DissertationTipo de Instituição Grupo Regional de PessoasDomínio Bibliotecas/RepositóriosSub-Domínio —-Versão V1.0Singapura 0Baseado em modsNovos termos 1Binding XMLMetodologia 1FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a


http://www.driver-support.eu/


Tabela C.18: Perfil de Aplicação de metadados MPEG-21 DIDL

Acrónimo MPEG-21 DIDLAno 2009Nome MPEG21 DIDL Application Profile for Institutional Reposi-

toriesTipo de Instituição n/dDomínio Bibliotecas/RepositóriosSub-Domínio ——–Versão 3.0Singapura 0Baseado em dc, dcterms, didl,diiNovos termos 1Binding XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL http://wiki.surf.nl/display/standards/MPEG21+

DIDL+Application+Profile+for+Institutional+Repositories

URI n/d

Tabela C.19: Perfil de Aplicação de metadados DRC AP

Acrónimo DRC APAno 2010Nome Digital Resources Commons Application ProfileTipo de Instituição Grupo Regional de PessoasDomínio Bibliotecas/RepositóriosSub-Domínio —-Versão V1.2Singapura 0Baseado em dcNovos termos 0Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL n/aURI n/a


http://wiki.surf.nl/display/standards/MPEG21+DIDL+Application+Profile+for+Instit utional+Repositories




C.3.0.13 Domínio: Ciência

Tabela C.20: Lista dos Perfil de Aplicação de metadados no domínio da Ciência

CiênciaAcrónimo Nome Tabela SingapuraAno: 2006SWAP Scholary Works Application Profile C.21 SimAno: 2010APIARY AP Apiary Schema C.22 NãoDRYAD DRYAD C.23 SimMLAP Mathematical Library Application Profile C.24 Não

Tabela C.21: Perfil de Aplicação de metadados SWAP

Acrónimo SWAPAno 2006Nome Scholary Works Application ProfileTipo de Instituição Comunidade CientíficaDomínio CiênciaSub-Domínio Comunicação CientíficaVersão n/aSingapura 1Baseado em dc, dcterms, MARC, foafNovos termos 1Binding XMLMetodologia 0FR 1DM 1DSP 1Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.ukoln.ac.uk/repositories/digirep/

index/SWAPURI http://purl.org/eprint/terms/


http://www.ukoln.ac.uk/repositories/digirep/index/SWAP

http://www.ukoln.ac.uk/repositories/digirep/index/SWAP

http://purl.org/eprint/terms/


Tabela C.22: Perfil de Aplicação de metadados APIARY AP

Acrónimo Apiary APAno 2010Nome Apiary SchemaTipo de Instituição Comunidade CientíficaDomínio CiênciaSub-Domínio BiologyVersão draft V3.2Singapura 1Baseado em Darwin Core, dcNovos termos 1Binding XML and RDFMetodologia 1FR 1DM 1DSP 1Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://www.apiaryproject.org/metadata-schemaURI n/a

Tabela C.23: Perfil de Aplicação de metadados DRYAD

Acrónimo DRYADAno 2010Nome DRYADTipo de Instituição Grupo Regional de pessoasDomínio CiênciaSub-Domínio Data StoresVersão V3.0Singapura 1Baseado em dc, dcterms, SM, Darwin Core, BibioNovos termos 1Binding XMLMetodologia 0FR 1DM 1DSP 1Guia de Utilização 1Guia de Codificação de Sintaxe 0URL http://wiki.datadryad.org/Metadata-ProfileURI n/a


http://www.apiaryproject.org/metadata-schema

http://wiki.datadryad.org/Metadata-Profile


Tabela C.24: Perfil de Aplicação de metadados MLAP

Acrónimo MLAPAno 2010Nome Mathematical Library Application ProfileTipo de Instituição n/aDomínio CiênciaSub-Domínio MatemáticaVersão DraftSingapura 0Baseado em dcterms, DC collections, PRISMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 1Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://projecteuclid.org/documents/metadata/mlap/URI n/a


http://projecteuclid.org/documents/metadata/mlap/


C.3.0.14 Domínio: E-Government

Tabela C.25: Lista dos Perfis de Aplicação no domínio de E-Government

E-GovernmentAcrónimo Nome Tabela SingapuraAno: 2005GO-WMES Government of Ontario Web Metadata Element

SetC.26 Não

Ano: 2006DC-Gov AP Dublin Core Government Application Profile C.27 NãoAno: 2008e-GMS e-Government Metadata Standard C.28 NãoPSI AP Public Service Information Application Profile C.29 NãoAno: 2010OWMS Overheid.nl Web Metadata Standaard C.30 NãoAno: 2012ADMS Asset Description Metadata Schema C.31 Não

Tabela C.26: Perfil de Aplicação de metadados GO-WMES

Acrónimo GO-WMESAno 2005Nome Government of Ontario Web Metadata Element SetTipo de Instituição Governo NacionalDomínio E-GovernmentSub-Domínio —-Versão V1.0Singapura 0Baseado em dc, dctermsNovos termos 1Binding n/aMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.mgs.gov.on.ca/en/IAndIT/STEL02-047444.

htmlURI n/a


http://www.mgs.gov.on.ca/en/IAndIT/STEL02-047444.html

http://www.mgs.gov.on.ca/en/IAndIT/STEL02-047444.html


Tabela C.27: Perfil de Aplicação de metadados DC-Gov AP

Acrónimo DC-Gov APAno 2006Nome Dublin Core Government Application ProfileTipo de Instituição Organisação/Empresa InternacionalDomínio E-GovernmentSub-Domínio —-Versão working draftSingapura 0Baseado em dc, GO-ITS, GOVTALK, NZGLS, JHS143, OWMSNovos termos 0Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://dublincore.org/dcgapwiki/URI n/a

Tabela C.28: Perfil de Aplicação de metadados e-GMS

Acrónimo e-GMSAno 2008Nome e-Government Metadata StandardTipo de Instituição Governo NacionalDomínio E-GovernmentSub-Domínio —-Versão V2.0Singapura 0Baseado em n/aNovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://purl.oclc.org/NET/e-GMS_v2URI n/a


http://dublincore.org/dcgapwiki/

http://purl.oclc.org/NET/e-GMS_v2


Tabela C.29: Perfil de Aplicação de metadados PSI AP

Acrónimo PSI APAno 2008Nome Public Service Information Application ProfileTipo de Instituição Comunidade CientíficaDomínio E-GovernmentSub-Domínio —Versão n/aSingapura 0Baseado em dc, dcterms, agls, eGMS, GILS, GovMLNovos termos 0Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a

Tabela C.30: Perfil de Aplicação de metadados OWMS

Acrónimo OWMSAno 2010Nome Overheid.nl Web Metadata StandaardTipo de Instituição Governo NacionalDomínio E-GovernmentSub-Domínio —-Versão V4.0Singapura 0Baseado em dc, dctermsNovos termos 1Binding RDFMetodologia 0FR 1DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://standaarden.overheid.nl/owms/4.0/doc/URI http://standaarden.overheid.nl/owms/terms/


http://standaarden.overheid.nl/owms/4.0/doc/

http://standaarden.overheid.nl/owms/terms/


Tabela C.31: Perfil de Aplicação de metadados ADMS

Acrónimo ADMSAno 2012Nome Asset Description Metadata SchemaTipo de Instituição Grupo Regional de PessoasDomínio E-GovernmentSub-Domínio —-Versão V1.0Singapura 0Baseado em dcterms, foaf, vcardNovos termos 0Binding RDFMetodologia 1FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL https://joinup.ec.europa.eu/asset/adms/homeURI http://www.w3.org/ns/adms


https://joinup.ec.europa.eu/asset/adms/home

http://www.w3.org/ns/adms


C.3.0.15 Domínio: Multi-domínio

Tabela C.32: Lista dos Perfis de Aplicação do domínio Multi-Domínio

Multi-domínioAcrónimo Nome Tabela SingapuraAno: 2002NZGLS New Zealand Government Locator

Service Metadata Element SetC.33 Não

Ano: 2006DC-EM AP Dublin Core E-Markets Application

ProfileC.34 Não

Ano: 2008Audovisual AP Audiovisual Application Profile C.35 NãoAno: 2009TBM-AP Time-based Media Application Pro-

fileC.36 Sim

VMAP Variazioni Musical Dublin Core Ap-plication Profile

C.37 Sim

Ano: 2010AGLS MS Australian Government Locator Ser-

vice Metadata StandardC.38 Não



Tabela C.33: Perfil de Aplicação de metadados NZGLS

Acrónimo NZGLSAno 2002Nome New Zealand Government Locator Service Metadata Element

SetTipo de Instituição Governo NacionalDomínio Multi-domínioSub-Domínio —-Versão V2.1Singapura 0Baseado em dc, dcterms, AGLSNovos termos 1Binding n/aMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.nzgls.govt.nz/URI n/a

Tabela C.34: Perfil de Aplicação de metadados DC-EM

Acrónimo DC-EMAno 2006Nome Dublin Core E-Markets Application ProfileTipo de Instituição Comunidade CientíficaDomínio Multi-domínioSub-Domínio E-marketsVersão n/aSingapura 0Baseado em dc, IEEE LOMNovos termos 1Binding XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL n/aURI n/a


http://www.nzgls.govt.nz/


Tabela C.35: Perfil de Aplicação de metadados Audovisual AP

Acrónimo Audovisual APAno 2008Nome Audiovisual Application ProfileTipo de Instituição Comunidade CientíficaDomínio Multi-domínioSub-Domínio —-Versão Em DesenvolvimentoSingapura 0Baseado em dc, PBCoreNovos termos 1Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a

Tabela C.36: Perfil de Aplicação de metadados TBM-AP

Acrónimo TBM-APAno 2009Nome Time-based Media Application ProfileTipo de Instituição Comunidade CientíficaDomínio Multi-domínioSub-Domínio EducaçãoVersão n/aSingapura 0Baseado em dc, dcterms, foaf, frbr, eprint, marcrel, tbmNovos termos 1Binding n/aMetodologia 0FR 1DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://wiki.manchester.ac.uk/tbmapURI n/a


http://wiki.manchester.ac.uk/tbmap


Tabela C.37: Perfil de Aplicação de metadados VMAP

Acrónimo VMAPAno 2009Nome Variazioni Musical Dublin Core Application ProfileTipo de Instituição Comunidade CientíficaDomínio Multi-domínioSub-Domínio MusicaVersão D23Singapura 1Baseado em dc, dcterms, foafNovos termos 1Binding RDFMetodologia 1FR 1DM 1DSP 1Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.variazioniproject.org/vmapURI http://purl.org/NET/vmap/ Purl working but URL to

where it is redirected is down. Responsible contacted in-formed us that there was no money to pay the URL.

Tabela C.38: Perfil de Aplicação de metadados AGLS MS

Acrónimo AGLS MSAno 2010Nome Australian Government Locator Service Metadata StandardTipo de Instituição Governo NacionalDomínio Multi-domínioSub-Domínio —-Versão AS 5044Singapura 0Baseado em dc, dcterms, Agent MT, Availability MTNovos termos 1Binding RDFMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.agls.gov.au/documents/aglsterms/URI http://www.agls.gov.au/agls/terms/


http://www.variazioniproject.org/vmap

http://purl.org/NET/vmap/

http://www.agls.gov.au/documents/aglsterms/

http://www.agls.gov.au/agls/terms/


C.3.0.16 Domínio: Objectos de Aprendizagem

Tabela C.39: Lista dos Perfis de Aplicação do domínio Objectos de Aprendizagem

Acrónimo Nome Tabela Enq.Singapura

Ano: 2002ANZ LOM ANZ LOM C.40 NãoFAILTE Facilitating Access to Information

on Learning Technology forEngineers Metadata Set

C.41 Não

Ano: 2003CelebrateAP

Celebrate Application Profile C.42 Não

CanCoreAP

CanCore Application Profile C.43 Não

FERL n/a C.44 NãoHLSI High Level Skills for Industry

Application ProfileC.45 Não

Ano: 2004LOMAP Objectos de Aprendizagem

Metadata Application ProfileC.46 Não

ManUel Métadonnées pour les ApplicationsNumériques de l’Université en Ligne

C.47 Não

OpenCartable OpenCartable C.48 NãoUK LOMCore

United Kingdom Objectos deAprendizagem Metadata Core

C.49 Não

SCORM Sharable Content Object ReferenceModel

C.50 Não

Ano: 2005

Ag-LR Agricultural Learning ResourceApplication Profile

C.51 Não

AraCore AraCore C.52 NãoNORMLOM Norvegian LOM Application Profile C.53 NãoTLF AP The Learning Federation

Application ProfileC.54 Não

Ano: 2006

MIMETA Modelo IACORIE de Metadatos C.55 Não

Continua...



Tabela C.39 – Continuação da página anterior...

Acrónimo Nome Tabela Enq.Singapura

Edna Edna C.56 NãoAno:2007

DC-Edu Dublin Core Education ApplicationProfile

C.57 Não

Vedata VET Metadata Application Profile C.58 Não

MELT Metadata Ecology for Learning andTeaching

C.59 Não

ReGov Rural-eGov Objectos deAprendizagem MetadataApplication Profile

C.60 Não

Ano:2008

Normetic Normetic C.61 Não

Ano:2009

OrganicEdu.net

Organic Edunet C.62 Não

CG LOM Consultative Group onInternational Agricultural Research

C.63 Não

RLLOMAP RDN/LTSN Objectos deAprendizagem MetadataApplication Profile

C.64 Não

Ano:2010

CerOrganicAP

Application Profile for DescribingCerOrganic DTOs

C.65 Não

LORELOM LORELOM C.66 Não

scoLOMFR scoLOMFR C.67 Não

Ano:2011

LREAP Learning Resource ExchangeMetadata Application Profile

C.68 Não

BEN Biosci Education Network MetadataDescription

C.69 Não

Tabela C.39 – Lista dos Perfis de Aplicação no domínio dos Objectos de Aprendizagem



Tabela C.40: Perfil de Aplicação de metadados ANZ LOM

Acrónimo ANZ LOMAno 2002Nome ANZ LOMTipo de Instituição Country OrganisationDomínio Objectos de AprendizagemSub-DomínioVersão V1.02Singapura 0Baseado em dc, dcterms, SCORM, IEEE LOMNovos termos 1Binding 0Metodologia 0FR 1DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a



Tabela C.41: Perfil de Aplicação de metadados FAILTE

Acrónimo FAILTEAno 2002Nome Facilitating Access to Information on Learning Technology

for Engineers Metadata SetTipo de Instituição Grupo Regional de pessoasDomínio Objectos de AprendizagemSub-Domínio EngineeringVersão V1.2Singapura 0Baseado em dc, IMSNovos termos 1Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.failte.ac.uk/documents/guidelines/

index.htmlURI n/a

Tabela C.42: Perfil de Aplicação de metadados Celebrate AP

Acrónimo Celebrate APAno 2003Nome Celebrate Application ProfileTipo de Instituição Grupo Internacional de pessoasDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.0Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a


http://www.failte.ac.uk/documents/guidelines/index.html

http://www.failte.ac.uk/documents/guidelines/index.html


Tabela C.43: Perfil de Aplicação de metadados CanCore AP

Acrónimo CanCore APAno 2003Nome CanCore Application ProfileTipo de Instituição Country Group of PeopleDomínio Objectos de AprendizagemSub-Domínio —-Versão V2.0Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologiaFR 1DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://cancore.athabascau.ca/en/URI n/a

Tabela C.44: Perfil de Aplicação de metadados FERL

Acronimo FERLAno 2003Nome n/aTipo de instituição Governo NacionalDomínio Objectos de AprendizagemUb-domínio —-Versão V1.0Singapura 0Baseado em dc, IMSNovos termos 1Binding n/aMetodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a


http://cancore.athabascau.ca/en/


Tabela C.45: Perfil de Aplicação de metadados HLSI

Acronimo HLSIAno 2003Nome High Level Skills for Industry APTipo de instituição Grupo de Pessoas NacionalDomínio Objectos de AprendizagemUb-domínio EngineeringVersão V1.0Singapura 0Baseado em IEEE LOMNovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL n/aURI n/a

Tabela C.46: Perfil de Aplicação de metadados LOMAP

Acrónimo LOMAPAno 2004Nome Objectos de Aprendizagem Metadata Application ProfileTipo de Instituição Comunidade CientíficaDomínio Objectos de AprendizagemSub-Domínio —-Versão n/aSingapura 0Baseado em IEEE LOMNovos termos 1Binding n/aMetodologia 1FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a



Tabela C.47: Perfil de Aplicação de metadados ManUel

Acrónimo ManUelAno 2004Nome Métadonnées pour les Applications Numériques de

l’Université en LigneTipo de Instituição Comunidade CientíficaDomínio Objectos de AprendizagemSub-Domínio Computer CiênciaVersão n/aSingapura 0Baseado em IEEE LOMNovos termos 1Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL n/aURI n/a

Tabela C.48: Perfil de Aplicação de metadados OpenCartable

Acrónimo OpenCartableAno 2004Nome OpenCartableTipo de Instituição n/aDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.1Singapura 0Baseado em IEEE LOM, dcNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL https://adullact.net/projects/opencartable/URI n/a


https://adullact.net/projects/opencartable/


Tabela C.49: Perfil de Aplicação de metadados UK LOM Core

Acrónimo UK LOM CoreAno 2004Nome United Kingdom Objectos de Aprendizagem Metadata CoreTipo de Instituição Country CommunityDomínio Objectos de AprendizagemSub-Domínio —-Versão Draft V 03_124Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://zope.cetis.ac.uk/profiles/uklomcore/URI n/a

Tabela C.50: Perfil de Aplicação de metadados SCORM

Acrónimo SCORMAno 2004Nome Sharable Content Object Reference ModelTipo de Instituição Organisação/Empresa NacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão V4Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.adlnet.gov/capabilities/scormURI n/a


http://zope.cetis.ac.uk/profiles/uklomcore/

http://www.adlnet.gov/capabilities/scorm


Tabela C.51: Perfil de Aplicação de metadados Ag-LR

Acrónimo Ag-LR APAno 2005Nome Agricultural Learning Resource Application ProfileTipo de Instituição Grupo Internacional de pessoasDomínio Objectos de AprendizagemSub-Domínio AgriculturaVersão n/aSingapura 0Baseado em dc, dcterms, AgMES, IEEE LOMNovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL http://aims.fao.org/metadata/sets/

ag-lr-application-profileURI n/a

Tabela C.52: Perfil de Aplicação de metadados AraCore

Acrónimo AraCoreAno 2005Nome AracoreTipo de Instituição Comunidade CientíficaDomínio Objectos de AprendizagemSub-Domínio —-Versão n/aSingapura 0Baseado em IEEE LOMNovos termos 0Binding n/aMetodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a


http://aims.fao.org/metadata/sets/ag-lr-application-profile

http://aims.fao.org/metadata/sets/ag-lr-application-profile


Tabela C.53: Perfil de Aplicação de metadados NORMLOM

Acrónimo NORMLOmAno 2005Nome Norvegian LOM Application ProfileTipo de Instituição Governo NacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.0Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.estandard.no/norlom/v1.0/URI n/a

Tabela C.54: Perfil de Aplicação de metadados TLF AP

Acrónimo TLF APAno 2005Nome The Learning Federation Application ProfileTipo de Instituição Governo NacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão finalSingapura 0Baseado em dc,dcterms, edna, IEEE LOMNovos termos 1Binding n/aMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://education.auURI n/a


http://www.estandard.no/norlom/v1.0/

http://education.au


Tabela C.55: Perfil de Aplicação de metadados MIMETA

Acrónimo MIMETAAno 2006Nome Modelo IACORIE de MetadatosTipo de Instituição n/aDomínio Objectos de AprendizagemSub-Domínio —-Versão n/aSingapura 0Baseado em IEEE LOM, dcNovos termos 1Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a

Tabela C.56: Perfil de Aplicação de metadados Edna

Acrónimo EdnaAno 2006Nome EdnaTipo de Instituição Governo NacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.0Singapura 0Baseado em dc, aglsNovos termos 1Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://edna.wikispaces.com/Elements+EdNA+

Metadata+Standard+1.1URI n/a


http://edna.wikispaces.com/Elements+EdNA+Metadata+Standard+1.1

http://edna.wikispaces.com/Elements+EdNA+Metadata+Standard+1.1


Tabela C.57: Perfil de Aplicação de metadados DC-Edu

Acrónimo DC-EduAno 2007Nome Dublin Core Education Application ProfileTipo de Instituição Organização InternacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão Working draft V0.4Singapura 0Baseado em dc, dcterms, IEEE LOMNovos termos 0Binding 0Metodologia 1FR 1DM 1DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL https://docs.google.com/Doc?id=dn8z3gs-38cgwkvvURI n/a

Tabela C.58: Perfil de Aplicação de metadados Vetadata

Acrónimo VetadataAno 2007Nome VET Metadata Application ProfileTipo de Instituição Governo NacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.0Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://e-standards.flexiblelearning.net.au/

technical-standards/metadata.phpURI n/a


https://docs.google.com/Doc?id=dn8z3gs-38cgwkvv

http://e-standards.flexiblelearning.net.au/technical-standards/metadata.php

http://e-standards.flexiblelearning.net.au/technical-standards/metadata.php


Tabela C.59: Perfil de Aplicação de metadados MELT

Acrónimo MELTAno 2007Nome Metadata Ecology for Learning and TeachingTipo de Instituição Grupo Internacional de PessoasDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.0Singapura 0Baseado em LRE APNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://info.melt-project.eu/ww/en/pub/

melt-project/project-deliverables.htmURI n/a


http://info.melt-project.eu/ww/en/pub/melt-project/project-deliverables.htm

http://info.melt-project.eu/ww/en/pub/melt-project/project-deliverables.htm


Tabela C.60: Perfil de Aplicação de metadados ReGov LOM

Acrónimo ReGov LOMAno 2007Nome Rural-eGov Objectos de AprendizagemMetadata Application

ProfileTipo de Instituição Organisação/Empresa InternacionalDomínio Objectos de AprendizagemSub-Domínio Agricultura (Rural Areas)Versão n/aSingapura 0Baseado em IEEE LOMNovos termos 0Binding n/aMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a

Tabela C.61: Perfil de Aplicação de metadados Normetic

Acrónimo NormeticAno 2008Nome NormeticTipo de Instituição Country Group of PeopleDomínio Objectos de AprendizagemSub-Domínio —-Versão V 1.2Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.normetic.org/URI n/a


http://www.normetic.org/


Tabela C.62: Perfil de Aplicação de metadados Organic Edu.net

Acrónimo Organic Edu.netAno 2009Nome Organic EdunetTipo de Instituição Grupo Internacional de pessoasDomínio Objectos de AprendizagemSub-Domínio AgriculturaVersão V2.0Singapura 0Baseado em IEEE LOMNovos termos 0Binding OWLMetodologia 1FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://wiki.agroknow.gr/organic-edunet/index.php/

Organic.Edunet-Metadata-Application-ProfileURI n/a

Tabela C.63: Perfil de Aplicação de metadados CG LOM

Acrónimo CG LOMAno 2009Nome Consultative Group on International Agricultural ResearchTipo de Instituição Organisação/Empresa InternacionalDomínio Objectos de AprendizagemSub-Domínio AgriculturaVersão n/aSingapura 0Baseado em IEEE LOMNovos termos 0Binding XML and RDFMetodologia 1FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL https://lirias.kuleuven.be/bitstream/123456789/

295784/1/IJMSO%2B41202%2BZschocke%2Bet%2Bal..pdf+&hl=en

URI n/a


http://wiki.agroknow.gr/organic-edunet/index.php/Organic.Edunet-Metadata-Appl ication-Profile

http://wiki.agroknow.gr/organic-edunet/index.php/Organic.Edunet-Metadata-Appl ication-Profile

https://lirias.kuleuven.be/bitstream/123456789/295784/1/IJMSO%2B41202%2BZschocke %2Bet%2Bal..pdf+&hl=en




Tabela C.64: Perfil de Aplicação de metadados RLLOMAP

Acrónimo RLLOMAPAno 2009Nome RDN/LTSN Objectos de Aprendizagem Metadata Applica-

tion ProfileTipo de Instituição Comunidade CientíficaDomínio Objectos de AprendizagemSub-DomínioVersão V1.0Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 1DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.intute.ac.uk/publications/rdn-ltsn/ap/URI n/a

Tabela C.65: Perfil de Aplicação de metadados CerOrganic AP

Acrónimo CerOrganic APAno 2010Nome Application Profile for Describing CerOrganic DTOsTipo de Instituição Grupo Internacional de pessoasDomínio Objectos de AprendizagemSub-Domínio AgriculturaVersão V0.2Singapura 0Baseado em IEEE LOM, LRE APNovos termos 0Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://wiki.agroknow.gr/cerorganic/index.php/

Main-PageURI n/a



http://wiki.agroknow.gr/cerorganic/index.php/Main-Page

http://wiki.agroknow.gr/cerorganic/index.php/Main-Page


Tabela C.66: Perfil de Aplicação de metadados LORELOM

Acrónimo LORELOMAno 2010Nome LORELOMTipo de Instituição Comunidade CientíficaDomínio Objectos de AprendizagemSub-Domínio Higher Education and UniversityVersão 1Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL http://wiki.surf.nl/display/standards/LORElomURI n/d

Tabela C.67: Perfil de Aplicação de metadados scoLOMFR

Acrónimo scoLOMFRAno 2010Nome scoLOMFRTipo de Instituição Governo NacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão V1.1Singapura 0Baseado em IEEE LOMNovos termos 0Binding 0Metodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a


http://wiki.surf.nl/display/standards/LORElom


Tabela C.68: Perfil de Aplicação de metadados LRE AP

Acrónimo LRE APAno 2011Nome Learning Resource Exchange Metadata Application ProfileTipo de Instituição Governo InternacionalDomínio Objectos de AprendizagemSub-Domínio —-Versão V4.5Singapura 0Baseado em IEEE LOMNovos termos 0Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://lreforschools.eun.org/web/guest/metadataURI n/a

Tabela C.69: Perfil de Aplicação de metadados BEN

Acrónimo BENAno 2011Nome Biosci Education Network Metadata DescriptionTipo de Instituição Grupo de Pessoas NacionalDomínio Objectos de AprendizagemSub-Domínio Biological CiênciasVersão V1.3.1Singapura 0Baseado em IEEE LOMNovos termos 0Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://saas.aaas.org/ben-wiki/doku.phpURI n/a


http://lreforschools.eun.org/web/guest/metadata

http://saas.aaas.org/ben-wiki/doku.php


C.3.0.17 Domínio: Património Cultural

Tabela C.70: Lista dos Perfis de Aplicação no domínio Património Cultural

Património CulturalAcrónimo Nome Tabela SingapuraAno: 2001MAG Comitato Metadati Amministrativi

GestionaliC.71 Não

Ano: 2004QuinkMap Quinkan Metadata Application Pro-

fileC.72 Não

Folklore Descrip-tion AP

Folklore Description ApplicationProfile

C.73 Não

Ano: 2007PICO PICO C.74 NãoAno: 2010EMAP EIAH Metadata Application Profile C.75 NãoAno: 2012ESE Europeana Semantic Elements C.76 NãoEDM Europeana Data Model C.77 Não

Tabela C.71: Perfil de Aplicação de metadados MAG

Acrónimo MAGAno 2001Nome Comitato Metadati Amministrativi GestionaliTipo de Instituição Organisação/Empresa NacionalDomínio Cultural heritageSub-Domínio Cultural Digital ObjectsVersão V2.0.1Singapura 0Baseado em dc, NISONovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://www.iccu.sbn.it/opencms/export/sites/iccu/

documenti/MAG-Reference-201-en.pdfURI n/a


http://www.iccu.sbn.it/opencms/export/sites/iccu/documenti/MAG-Reference-201-en. pdf

http://www.iccu.sbn.it/opencms/export/sites/iccu/documenti/MAG-Reference-201-en. pdf


Tabela C.72: Perfil de Aplicação de metadados QuinkMap

Acrónimo Quinkan MAPAno 2004Nome Quinkan Metadata Application ProfileTipo de Instituição Comunidade CientíficaDomínio Património CulturalSub-Domínio —-Versão n/aSingapura 0Baseado em dc,dcterms, aglsNovos termos 1Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a

Tabela C.73: Perfil de Aplicação de metadados Folklore Description AP

Acrónimo Folklore description APAno 2004Nome Folklore Description Application ProfileTipo de Instituição Comunidade CientíficaDomínio Património CulturalSub-Domínio CollectionsVersão n/aSingapura 0Baseado em dc, dcterms, dc collections, RSLP, MARC, ADL, IEEE LOMNovos termos 0Binding RDFMetodologia 0FR 1DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a



Tabela C.74: Perfil de Aplicação de metadados PICO

Acrónimo PICOAno 2007Nome PICOTipo de Instituição Organisação/Empresa NacionalDomínio OutrosSub-Domínio Recursos WebVersão n/aSingapura 0Baseado em dc, dctermsNovos termos 1Binding 0Metodologia 1FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL n/aURI n/a

Tabela C.75: Perfil de Aplicação de metadados EMAP

Acrónimo EMAPAno 2010Nome EIAH Metadata Application ProfileTipo de Instituição Comunidade CientíficaDomínio Património CulturalSub-Domínio —-Versão n/aSingapura 0Baseado em Dc-lib, MODSNovos termos 0Binding 0Metodologia 1FR 1DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL n/aURI n/a



Tabela C.76: Perfil de Aplicação de metadados ESE

Acrónimo ESEAno 2012Nome Europeana Semantic ElementsTipo de Instituição Governo InternacionalDomínio Património CulturalSub-Domínio —-Versão V3.4Singapura 0Baseado em dc, dctermsNovos termos 1Binding XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://pro.europeana.eu/technical-requirementsURI n/a

Tabela C.77: Perfil de Aplicação de metadados EDM

Acrónimo EDMAno 2012Nome Europeana Data ModelTipo de Instituição Organisação/Empresa InternacionalDomínio Património CulturalSub-Domínio —Versão V5.2.3Singapura 0Baseado em dc, dctermsNovos termos 1Binding RDFMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://pro.europeana.eu/web/guest/

edm-documentationURI http://www.europeana.eu/schemas/edm/


http://pro.europeana.eu/technical-requirements

http://pro.europeana.eu/web/guest/edm-documentation

http://pro.europeana.eu/web/guest/edm-documentation

http://www.europeana.eu/schemas/edm/


C.3.0.18 Domínio: Outros

Tabela C.78: Lista dos Perfil de Aplicação de metadados no domínio dos Outros

OutrosAcrónimo Nome Tabela SingapuraAno: 2001IOAP On Line Journal C.79 NãoAno: 2008

OAI-ORE Open Archives Initiative - ObjectReuse and Exchange C.80 Não

Ano: 2009

CRAP Application Profile for Ceramic Re-sources C.81 Não

Ano: 2010IAP Image Application Profile C.82 SimAno: 2012

DCAP2AP Dublin Core Application Profile toAnalysis Patterns C.83 Não

Tabela C.79: Perfil de Aplicação de metadados IOAP

Acrónimo IOAPAno 2001Nome On Line JournalTipo de Instituição Comunidade CientíficaDomínio OutrosSub-Domínio Revista On LineVersão n/aSingapura 0Baseado em dcterms, VcardNovos termos 1Binding XMLMetodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://www.dsi.uminho.pt/io/schemas/io-schemaURI n/a


http://www.dsi.uminho.pt/io/schemas/io-schema


Tabela C.80: Perfil de Aplicação de metadados OAI-ORE

Acrónimo OAI-OREAno 2008Nome Open Archives Initiative - Object Reuse and ExchangeTipo de Instituição Comunidade CientíficaDomínio OutrosSub-Domínio Recursos da Web agregadosVersão 1.0Singapura 0Baseado em dc, dcterms, foaf, oreNovos termos 1Binding RDF/XMLMetodologia 0FR 0DM 1DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 0URL http://www.openarchives.org/ore/URI http://www.openarchives.org/ore/terms/

Tabela C.81: Perfil de Aplicação de metadados CRAP

Acrónimo CRAPAno 2009Nome Application Profile for Ceramic ResourcesTipo de Instituição Comunidade CientíficaDomínio OutrosSub-Domínio ———Versão n/dSingapura 0Baseado em CDWA LiteNovos termos 1Binding RDFMetodologia 0FR 0DM 0DSP 0Guia de Utilização 0Guia de Codificação de Sintaxe 0URL http://metadataregistry.org/schema/show/id/19.

htmlURI http://metadataregistry.org/uri/schema/crap.rdf



http://www.openarchives.org/ore/terms/



http://metadataregistry.org/uri/schema/crap.rdf


Tabela C.82: Perfil de Aplicação de metadados IAP

Acrónimo IAPAno 2008Nome Image Application ProfileTipo de Instituição Comunidade CientíficaDomínio OutrosSub-Domínio ImagensVersão final/work in progressSingapura 1Baseado em FRBR, dc, mixNovos termos 1Binding 0Metodologia 1FR 1DM 1DSP 1Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.ukoln.ac.uk/repositories/digirep/

index/The-Images-Application-ProfileURI n/a

Tabela C.83: Perfil de Aplicação de metadados DC2AP

Acrónimo DC2APAno 2012Nome Dublin Core Application Profile to Analysis PatternsTipo de Instituição Comunidade CientíficaDomínio OutrosSub-Domínio Desenvolvimento de softwareVersão n/dSingapura 0Baseado em dc, dctermsNovos termos 1Binding RDFMetodologia 0FR 0DM 0DSP 0Guia de Utilização 1Guia de Codificação de Sintaxe 1URL http://www.dpi.ufv.br/projetos/apri/?page_id=193URI http://dpi.ufv.br/projetos/apri/dc2ap/elements/

DC2APElements.rdf


http://www.ukoln.ac.uk/repositories/digirep/index/The-Images-Application-Profile

http://www.ukoln.ac.uk/repositories/digirep/index/The-Images-Application-Profile

http://www.dpi.ufv.br/projetos/apri/?page_id=193

http://dpi.ufv.br/projetos/apri/dc2ap/elements/DC2APElements.rdf

http://dpi.ufv.br/projetos/apri/dc2ap/elements/DC2APElements.rdf


C.3.1 Perfis de Aplicação de metadados excluídos do estudo

Na pesquisas seleccionamos um total de 83 PA. Contudo, 9 deles foram excluídos porque, depoisde serem analisados, concluimos que não eram adequados ao nosso estudo. Apesar disso, achamosimportante apresentar esses perfis juntamente com a informação com a razão pela qual não foramincluídos no estudo. (ver tabela C.84). As razões foram:

• Sem informação sobre os esquemas de metadados: Não foi encontrada informação sobre osesquemas de metadados utilizados para descrever os registos de metadados do PA;

• Sem informação: Apesar de todos os esforços não foi possível encontrar informação consis-tente sobre o PA;

• Ausência de informação: Não recebemos nenhuma resposta aos emails enviados aos autoresdos artigos científicos onde os PA foram descritos;

• Privado: As definições do PA não são públicas;

• URL em baixo: A única fonte de informação sobre o PA não estava disponível;

• Esquema Conceptual: Não era de facto um PA uma vez que somente apresentou umesquema conceptual dos dados.

A referência ao facto de que o PA MERLOT não é de acesso público foi encontrada no artigoGodby (2004). O PA MODDEC foi referido por Moura et al. (2002). O PA TragLor foi referidoem Godby (2004) e descrito em Cebeci et al. (2008).


C.A

nálisedos

Perfisde

Aplicação

demetadados

Tabela C.84: Perfis de Aplicação seleccionados mas não utilizados no estudo

Acrónimo Nome URL RazãoABCD Access to Biological Colecções

Data - Schemahttp://wiki.tdwg.org/twiki/bin/view/ABCD/ Sem informação sobre os

esquemas de metadados.GEM Metadata element set for the

Gateway to Educational Mate-rials

http://www.thegateway.org/ Ausência de informação.Contactado através doSítio Web. Nenhumaresposta.

Geospatial DCAP Geospatial DCAP n/a Sem informação.MCPD FAO/IPGRI Multi-Crop Pass-

port Descriptorshttp://genbank.vurv.cz/ewdb/asp/multicrp.htm Sem informação sobre os

esquemas de metadados.MERLOT — http://www.merlot.org/merlot/index.htm Privado.MODDEC —– n/d Modelo Conceptual.SPATL Spatial Standards and Norms http://aims.fao.org/metadata/sets/

spatial-standard-and-normsSem informação sobre osesquemas de metadados.

The CurriculumOn-Line

The Curriculum On-Line n/a URL em baixo.

TrAgLor The Turkish Agricultural Ob-jectos de Aprendizagem

n/a Falta de informação.

322Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

http://wiki.tdwg.org/twiki/bin/view/ABCD/

http://www.thegateway.org/

http://genbank.vurv.cz/ewdb/asp/multicrp.htm

http://www.merlot.org/merlot/index.htm

http://aims.fao.org/metadata/sets/spatial-standard-and-norms

http://aims.fao.org/metadata/sets/spatial-standard-and-norms


C.4 Matriz II - esquemas de metadados base

Os esquemas de metadados foram categorizados segundo um conjunto de domínios (ver Ta-bela C.85). A Tabela C.86 apresenta os esquemas de metadados utilizados pelos PA seleccionadosna secção 6.3.1.3.4. Cada esquema de metadados é apresentado com um nome e um acrónimo, umURL e um URI. Utilizamos o termo ”n/d“ quando não há informação disponível. Os esquemasde metadados estão listados por domínio de aplicação e, dentro de cada categoria de domínio,apresentam-se por ordem alfabética.

Tabela C.85: Classificação dos Esquemas de Metadados

DomínioAgriculturaAudio/Vídeo/MultimédiaBibliotecas/RepositóriosCiênciaColecçõesComércio ElectrónicoComunicação Científica, EditoresDescrição ou/e relação de/entre pessoas, comunidades ou organizaçõesE-GovernmentImagensMulti-DomínioObjectos de AprendizagemPatrimónio CulturalOutros


C.A

nálisedos

Perfisde

Aplicação

demetadados

Tabela C.86: Lista dos Esquemas de Metadados por domínio

Nome Acrónimo URL URIAgriculturaAgricuture metadata ele-ment set

agMES http://aims.fao.org/standards/agmes http://purl.org/agmes/1.1/

Audio/Vídeo/MultimédiaPublic Broadcasting Meta-data Dictionary Project

PBCore http://pbcore.org/schema n/d

Technical Metadata for Au-dio and Video

AudioMDand Vide-oMD

http://www.loc.gov/standards/amdvmd/

index.html

n/d

Time-Based Media TermsVocabulary

TBM http://wiki.manchester.ac.uk/tbmap/

index.php/TBMTerms

http://example.org/tbm/terms/

Bibliotecas/RepositóriosAlexandria Digital Librarycollection metadata

ADL http://www.alexandria.ucsb.edu/docs/

metadata/ADL-collection-metadata.dtd

n/d

Bibliographic Ontology BIBO http://bibliontology.com/ http://purl.org/ontology/bibo/

Dublin Core AP for Libra-rians

DC-Lib http://dublincore.org/documents/

library-application-profile/

n/d

Encoded Archival Descrip-tion

EAD http://www.loc.gov/ead/eadschema.html n/d

Functional Requirementsfor Bibliographic Records

FRBR http://www.ifla.org/VII/s13/frbr/frbr.

pdf

http://iflastandards.info/ns/fr/frbr/

frbrer/

Functional Requirementsfor Authority Data

FRAD http://www.ifla.org/publications/

functional-requirements-for-authority-data

http://iflastandards.info/ns/fr/frad/


324Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

http://aims.fao.org/standards/agmes

http://purl.org/agmes/1.1/

http://pbcore.org/schema

http://www.loc.gov/standards/amdvmd/index.html

http://www.loc.gov/standards/amdvmd/index.html

http://wiki.manchester.ac.uk/tbmap/index.php/TBMTerms

http://wiki.manchester.ac.uk/tbmap/index.php/TBMTerms

http://example.org/tbm/terms/

http://www.alexandria.ucsb.edu/docs/metadata/ADL-collection-metadata.dtd

http://www.alexandria.ucsb.edu/docs/metadata/ADL-collection-metadata.dtd

http://bibliontology.com/

http://purl.org/ontology/bibo/



http://www.loc.gov/ead/eadschema.html

http://www.ifla.org/VII/s13/frbr/frbr.pdf

http://www.ifla.org/VII/s13/frbr/frbr.pdf

http://iflastandards.info/ns/fr/frbr/frbrer/

http://iflastandards.info/ns/fr/frbr/frbrer/

http://www.ifla.org/publications/functional-requirements-for-authority-data

http://www.ifla.org/publications/functional-requirements-for-authority-data

http://iflastandards.info/ns/fr/frad/

C.A

nálisedos

Perfisde

Aplicação

demetadados

Tabela C.86 – continuação

Nome Acrónimo URL URIFunctional Requirementsfor Subject Authority Data

FRSAD http://www.ifla.org/files/

classification-and-indexing/

functional-requirements-for-subject-authority-data/

frsad-final-report.pdf

http://iflastandards.info/ns/fr/frsad/

International Standard Ar-chival Description

ISAD http://www.ica.org/10207/standards/

isadg-general-international-standard-archival-description-second-edition.

html

n/d

Machine-Readable Catalo-ging

MARC http://www.loc.gov/marc/ n/d

Metadata Encoding andTransmission Standard

METS http://www.loc.gov/standards/mets/ http://www.loc.gov/METS/

Metadata Encoding andTrasnmission StandardRights (extension ofMETS)

METSRights http://www.loc.gov/standards/rights/

METSRights.xsd

n/d

CiênciaDarwin Core Darwin

Corehttp://rs.tdwg.org/dwc/index.htm http://rs.tdwg.org/dwc/terms/

ColecçõesCollection DescriptionTerms

CLD http://dublincore.org/groups/

collections/collection-terms/

http://purl.org/cld/terms/

MICHAEL Project Terms michael n/d http://example.org/michael/terms/

OAI Object Reuse and Ex-change

ORE http://www.openarchives.org/ore/ http://www.openarchives.org/ore/terms/


Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

325

http://www.ifla.org/files/classification-and-indexing/functional-requirements-fo r-subject-authority-data/frsad-final-report.pdf




http://iflastandards.info/ns/fr/frsad/

http://www.ica.org/10207/standards/isadg-general-international-standard-archival -description-second-edition.html



http://www.loc.gov/marc/

http://www.loc.gov/standards/mets/

http://www.loc.gov/METS/

http://www.loc.gov/standards/rights/METSRights.xsd

http://www.loc.gov/standards/rights/METSRights.xsd

http://rs.tdwg.org/dwc/index.htm

http://rs.tdwg.org/dwc/terms/

http://dublincore.org/groups/collections/collection-terms/

http://dublincore.org/groups/collections/collection-terms/

http://purl.org/cld/terms/

http://example.org/michael/terms/



C.A

nálisedos

Perfisde

Aplicação

demetadados


Nome Acrónimo URL URIRenardus Collection LevelDescription

RCLD http://renardus.sub.uni-goettingen.de/

renap/rcld.html

n/d

The Renardus MetadataElement Set

rmes http://renardus.sub.uni-goettingen.de/

renap/rmes.html

n/d

The Renardus MetadataElement Set Qualifiers

rmesq http://renardus.sub.uni-goettingen.de/

renap/rmesq.html

n/d

Research Support Libra-ries Programme CollectionsDescription Schema

RSLP http://www.ukoln.ac.uk/metadata/rslp/ n/d

Comércio ElectrónicoGood Relations GR http://www.heppnetz.de/projects/

goodrelations/


Comunicação Científica, EditoresEprints Terms EPRINTS http://www.ukoln.ac.uk/repositories/

digirep/index/Eprints/Terms


Publishing Requirementsfor Industry Standard Me-tadata

PRISM http://www.prismstandard.org/

specifications

http://prismstandard.org/namespaces/

basic/2.0/

Descrição ou/e relação de/entre pessoas, comunidades ou organizaçõesFriend of a Friend FOAF http://xmlns.com/foaf/spec/ http://xmlns.com/foaf/0.1/

An organization ontology ORG http://www.epimorphics.com/public/

vocabulary/org.html


SIOC COre Ontology Spe-cification

SIOC http://rdfs.org/sioc/spec/ http://rdfs.org/sioc/ns#


326Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

http://renardus.sub.uni-goettingen.de/renap/rcld.html

http://renardus.sub.uni-goettingen.de/renap/rcld.html

http://renardus.sub.uni-goettingen.de/renap/rmes.html

http://renardus.sub.uni-goettingen.de/renap/rmes.html

http://renardus.sub.uni-goettingen.de/renap/rmesq.html

http://renardus.sub.uni-goettingen.de/renap/rmesq.html

http://www.ukoln.ac.uk/metadata/rslp/

http://www.heppnetz.de/projects/goodrelations/

http://www.heppnetz.de/projects/goodrelations/


http://www.ukoln.ac.uk/repositories/digirep/index/Eprints/Terms

http://www.ukoln.ac.uk/repositories/digirep/index/Eprints/Terms


http://www.prismstandard.org/specifications

http://www.prismstandard.org/specifications

http://prismstandard.org/namespaces/basic/2.0/

http://prismstandard.org/namespaces/basic/2.0/

http://xmlns.com/foaf/spec/

http://xmlns.com/foaf/0.1/

http://www.epimorphics.com/public/vocabulary/org.html

http://www.epimorphics.com/public/vocabulary/org.html


http://rdfs.org/sioc/spec/

http://rdfs.org/sioc/ns#

C.A

nálisedos

Perfisde

Aplicação

demetadados


Nome Acrónimo URL URIE-Governmente-Government MetadataStandard

eGMS http://www.esd.org.uk/standards/egms/ n/d

Government InformationLocation Service

GILS http://www.gils.net/prof/v2.html n/d

Governmental Markup Lan-guage

GovML http://xml.coverpages.org/govML.html n/d

GO-ITS 43 Web Metadata GO-ITS 43 http://www.mgs.gov.on.ca/en/IAndIT/

STEL02/047303.html

n/d

Overheid.nl Web MetadataStandaard

OWMS http://standaarden.overheid.nl/owms/4.

0/doc/

http://standaarden.overheid.nl/owms/

terms/

The Finnish metadata stan-dard

JHS 143 http://www.jhs-suositukset.fi/web/

guest/jhs/recommendations/143

http://www.jhs-suositukset.fi/suomi/

jhs143

ImagensMetadata for Images inXML Schema

MIX http://www.loc.gov/standards/mix/ n/d

Technical Metadata for Op-tical Character Recognition

ALTO http://www.loc.gov/standards/alto/ n/d

Multi-DomínioAGLS Metadata Standard AGLS http://www.agls.gov.au/documents/

aglsterms/


AGLS Availability Meta-data Terms

AvailabilityMT

n/d http://www.agls.gov.au/agls/availterms


Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

327

http://www.esd.org.uk/standards/egms/

http://www.gils.net/prof/v2.html

http://xml.coverpages.org/govML.html

http://www.mgs.gov.on.ca/en/IAndIT/STEL02/047303.html

http://www.mgs.gov.on.ca/en/IAndIT/STEL02/047303.html





http://www.jhs-suositukset.fi/web/guest/jhs/recommendations/143

http://www.jhs-suositukset.fi/web/guest/jhs/recommendations/143

http://www.jhs-suositukset.fi/suomi/jhs143

http://www.jhs-suositukset.fi/suomi/jhs143

http://www.loc.gov/standards/mix/

http://www.loc.gov/standards/alto/




http://www.agls.gov.au/agls/availterms

C.A

nálisedos

Perfisde

Aplicação

demetadados


Nome Acrónimo URL URIAGLS Agent MetadataTerms

Agent MT n/d http://www.agls.gov.au/agls/agentterms

Dublin Core DC http://dublincore.org/documents/dces/ http://purl.org/dc/elements/1.1/

Dublin Core Terms (refine-ment of DC)

DCTerms http://dublincore.org/documents/

dcmi-terms/


NZGLS metadata standard NZGLS http://archive.ict.govt.nz/plone/

archive/standards/nzgls/standard/index.

html

n/d

Objectos de AprendizagemDublin Core AP for Educa-tion

DC-Edu https://docs.google.com/Doc?id=dn8z3gs/

38cgwkvv

n/d

IMS Global Learning Con-sorcium

IMS http://www.imsglobal.org/metadata/ n/d

Learning Object Metadata IEEE LOM http://ltsc.ieee.org/wg12/ n/dUK Learning Object Meta-data Core

UK LOM http://zope.cetis.ac.uk/profiles/

uklomcore

n/d

Património CulturalCategories for the Descrip-tion of Works of Art

CDWA Lite http://www.getty.edu/research/

publications/electronic_publications/

cdwa/cdwalite.html

n/d

Lightweight InformationDescribing Objects schema

LIDO http://network.icom.museum/

cidoc/working-groups/

data-harvesting-and-interchange/

lido-technical/specification/

n/d


328Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

http://www.agls.gov.au/agls/agentterms


http://purl.org/dc/elements/1.1/

http://dublincore.org/documents/dcmi-terms/

http://dublincore.org/documents/dcmi-terms/


http://archive.ict.govt.nz/plone/archive/standards/nzgls/standard/index.html



https://docs.google.com/Doc?id=dn8z3gs/38cgw kvv

https://docs.google.com/Doc?id=dn8z3gs/38cgw kvv

http://www.imsglobal.org/metadata/

http://ltsc.ieee.org/wg12/



http://www.getty.edu/research/publications/electronic_publications/cdwa/cdwalite .html



http://network.icom.museum/cidoc/working-groups/data-harvesting-and-interchange/ lido-technical/specification/




C.A

nálisedos

Perfisde

Aplicação

demetadados


Nome Acrónimo URL URIOutrosOpen Archives Initiative- Object Reuse and Ex-change

ORE http://www.openarchives.org/ore/1.0/

vocabulary.html


Preservation MetadataSchema

PREMIS http://www.loc.gov/standards/premis/ n/d

Technical Metadata forText

TEXTMD http://www.loc.gov/standards/textMD/ n/d

Guideline Elements Model GEM http://gem.med.yale.edu n/dTabela C.86 – Lista dos Esquemas de Metadados por domínio

Contributo

metodológico

paraodesenvolvim

entode

perfisde

aplicaçãono

contextoda

Web

Semântica

329

http://www.openarchives.org/ore/1.0/vocabulary.html

http://www.openarchives.org/ore/1.0/vocabulary.html


http://www.loc.gov/standards/premis/

http://www.loc.gov/standards/textMD/

http://gem.med.yale.edu


C.5 Matriz III - esquemas de codificação

Nesta secção apresentamos a informação referente aos esquemas de codificação utilizados nos PAretidos no estado da arte do contexto de aplicação (c.f secção 6.3.1.3.6):

• Esquemas de codificação de sintaxe )(Syntax Enconding Schemes (SES)): Estes esquemasestão listados na Tabela C.87. Esta informação está organizada por ordem alfabética doNome.

• Esquemas de codificação de vocabulário (Vocabulary Enconding Schemes (VES)): Estesesquemas estão listados na Tabela C.88. Esta informação não tem qualquer tipo deordenação.

A descrição dos esquemas está em Inglês por ter sido retirada da sua documentação.

Tabela C.87: Esquemas de codificação de sintaxe

Nome: AGLS AvailabilityDefinição: The availability property provides information about how to obtain offline

resources. Agents are people, organisations or instruments associatedwith resources. The AGLS Availability Syntax Encoding Scheme isa method for describing characteristics of agents in AGLS metadatadescriptions. Values for the availability property will contain informationabout the agent making the resource available.

URI: http://www.agls.gov.au/agls/terms/AglsAvailVer: http://www.agls.gov.au/documents/AglsAvail/

Nome: AGLS AgentDefinição: The creator, publisher, contributor and rightsHolder properties provide

information about agents associated with a resource. Agents are people,organisations or instruments associated with resources. The AGLS AgentSyntax Encoding Scheme is a method for describing characteristics ofagents in AGLS metadata descriptions.

URI: http://www.agls.gov.au/agls/AglsAgent/Ver: http://www.agls.gov.au/documents/AglsAgent/

Nome: DCMI PointDefinição: The set of points in space defined by their geographic coordinates accor-

ding to the DCMI Point Encoding Scheme.URI: http://purl.org/dc/terms/PointVer: http://dublincore.org/usage/terms/history/#Point-003



http://www.agls.gov.au/documents/AglsAvail/

http://www.agls.gov.au/documents/AglsAgent/

http://dublincore.org/usage/terms/history/#Point-003


Ccontinuação

Nome: DCMI BoxDefinição: The set of regions in space defined by their geographic coordinates

according to the DCMI Box Encoding Scheme.URI: http://purl.org/dc/terms/BoxVer: http://dublincore.org/documents/dcmi-box/

Nome: DCMI PeriodDefinição: The set of time intervals defined by their limits according to the DCMI

Period Encoding Scheme.URI: http://purl.org/dc/terms/PeriodVer: http://dublincore.org/documents/dcmi-period/

Nome: ISO 3166-1Definição: The set of codes listed in ISO 3166-1 for the representation of names of

countries.URI: http://purl.org/dc/terms/ISO3166Ver: http://www.iso.org/iso/iso_catalogue/catalogue_tc/

catalogue_detail.htm?csnumber=39719

Nome: ISO 3166-2Definição: Codes for the representation of names of countries and their subdivisions

– Part 2: Country subdivision code.URI: http://purl.org/dc/terms/ISO3166Ver: http://www.iso.org/iso/iso_catalogue/catalogue_tc/

catalogue_detail.htm?csnumber=39718

Nome: ISO 639-2Definição: The three-letter alphabetic codes listed in ISO639-2 for the representation

of names of languages.URI: http://purl.org/dc/terms/ISO639-2Ver: http://lcweb.loc.gov/standards/iso639-2/langhome.html

Nome: RFC 1766Definição: The set of tags, constructed according to RFC 1766, for the identification

of languages.URI: http://purl.org/dc/terms/RFC1766Ver: http://dublincore.org/usage/terms/history/#RFC1766-003



http://dublincore.org/documents/dcmi-box/

http://dublincore.org/documents/dcmi-period/

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber= 39719




http://lcweb.loc.gov/standards/iso639-2/langhome.html

http://dublincore.org/usage/terms/history/#RFC1766-003


Ccontinuação

Nome: RFC 3066Definição: The set of tags constructed according to RFC 3066 for the identification

of languages. RFC 3066 has been obsoleted by RFC 4646.URI: http://purl.org/dc/terms/RFC3066Ver: http://www.ietf.org/rfc/rfc3066.txt

Nome: RFC 4646Definição: A language tag for use in cases where it is desired to indicate the

language used in an information object, how to register values for use inthis language tag, and a construct for matching such language tags.

URI: http://purl.org/dc/terms/RFC3066Ver: http://www.ietf.org/rfc/rfc3066.txt

Nome: URIDefinição: The set of identifiers constructed according to the generic syntax for

Uniform Resource Identifiers as specified by the Internet EngineeringTask Force.

URI: http://purl.org/dc/terms/URIVer: http://www.ietf.org/rfc/rfc3986.txt

Nome: W3C-DTFDefinição: The set of dates and times constructed according to the W3C Date and

Time Formats Specification.URI: http://purl.org/dc/terms/W3CDTFVer: http://www.w3.org/TR/NOTE-datetime

Tabela C.87 – Esquemas de codificação de sintaxe

Tabela C.88: Esquemas de codificação de vocabulário

Nome: DCMI Type VocabularyURI: http://purl.org/dc/terms/DCMITypeDefinição: The set of classes specified by the DCMI Type Vocabulary, used to

categorize the nature or genre of the resource.Ver: http://dublincore.org/documents/dcmi-type-vocabulary/Ver: http://purl.org/dc/dcmitype/

Nome: DDCContinua na página seguinte...


http://www.ietf.org/rfc/rfc3066.txt



http://www.w3.org/TR/NOTE-datetime

http://purl.org/dc/dcmitype/


Continuação

Definição: The set of conceptual resources specified by the Dewey Decimal Classifi-cation.

URI: http://purl.org/dc/terms/DDCVer: http://www.oclc.org/dewey/

Nome: IMTDefinição: The set of media types specified by the Internet Assigned Numbers

Authority.URI: http://purl.org/dc/terms/IMTVer: http://www.iana.org/assignments/media-types/

Nome: LCCDefinição: The set of conceptual resources specified by the Library of Congress

Classification.URI: http://purl.org/dc/terms/LCCVer: http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html

Nome: LCSHDefinição: The set of labeled concepts specified by the Library of Congress Subject

Headings.URI: http://purl.org/dc/terms/LCSHVer: n/a

Nome: LCNAFDefinição: The Library of Congress Nome Authority File file provides authoritative

data for names of persons, organizations, events, places, and titles. Itspurpose is the identification of these entities and, through the use ofsuch controlled vocabulary, to provide uniform access to bibliographicresources. Nomes descriptions also provide access to a controlled formof name through references from unused forms, e.g. a search under:Snodgrass, Quintus Curtius, 1835-1910 will lead users to the authoritativename for Mark Twain, which is Twain, Mark, 1835-1910. Names mayalso be used as subjects in bibliographic descriptions, so they may becombined with controlled values from subject heading schemes, such asLCSH.

URI: http://id.loc.gov/authorities/namesVer: http://id.loc.gov/authorities/names.html



http://www.oclc.org/dewey/

http://www.iana.org/assignments/media-types/

http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html

http://id.loc.gov/authorities/names.html


Continuação

Nome: MeSHDefinição: The set of labeled concepts specified by the Medical Subject Headings.URI: http://purl.org/dc/terms/MESHVer: http://www.nlm.nih.gov/mesh/meshhome.html

Nome: NLMDefinição: The set of conceptual resources specified by the National Library of

Medicine Classification.URI: http://purl.org/dc/terms/NLMVer: http://wwwcf.nlm.nih.gov/class/

Nome: TGNDefinição: The set of places specified by the Getty Thesaurus of Geographic Nomes.URI: http://purl.org/dc/terms/TGNVer: http://www.getty.edu/research/tools/vocabulary/tgn/index.

html

Nome: UDCDefinição: The set of conceptual resources specified by the Universal Decimal

Classification.URI: http://purl.org/dc/terms/UDCVer: http://www.udcc.org/

Nome: AGLS ServiceDefinição: The serviceType property provides information about service types when

a resource is a service. The AGLS Service Vocabulary Encoding Schemeis a controlled list of terms for providing service type values in AGLSmetadata records. This list describes the logical form of the service andis not governed by the format of the service. Service types described maybe online or offline.

URI: http://www.agls.gov.au/agls/terms/agls-serviceVer: http://www.agls.gov.au/documents/agls-service/

Nome: AGLS DocumentContinua na página seguinte...


http://www.nlm.nih.gov/mesh/meshhome.html

http://wwwcf.nlm.nih.gov/class/

http://www.getty.edu/research/tools/vocabulary/tgn/index.html

http://www.getty.edu/research/tools/vocabulary/tgn/index.html

http://www.udcc.org/

http://www.agls.gov.au/documents/agls-service/


Continuação

Definição: The documentType property provides information about document typeswhen a resource is a document. The AGLS Document VocabularyEncoding Scheme is a controlled list of terms for providing documenttype values in AGLS metadata records. This list describes the logicalform of the resource and is not governed by the format of the document.Document types described may be digital or non-digital.

URI: http://www.agls.gov.au/agls/terms/agls-documentVer: http://www.agls.gov.au/documents/agls-document/

Nome: AGLS JurisdictionDefinição: The AGLS Jurisdiction Vocabulary Encoding Scheme is a controlled list

of terms for providing Australian jurisdiction values in AGLS metadatarecords.

URI: http://www.agls.gov.au/agls/terms/AglsJuriVer: http://www.agls.gov.au/documents/AglsJuri/

Nome: AGLS AudienceDefinição: The audience property provides information about the target audience for

whom a resource is intended. The AGLS Audience Vocabulary EncodingScheme is a controlled list of terms for providing audience type values inAGLS metadata records.

URI: http://www.agls.gov.au/agls/agls-audience/Ver: http://www.agls.gov.au/documents/agls-audience/

Nome: PRONOMDefinição: PRONOM is a technical registry that contains information about File

Formats, Software Packages, Compression Types and Character Enco-dings.

URI: http://test.linkeddatapronom.nationalarchives.gov.uk/vocabulary/pronom-vocabulary.rdf

Ver: http://test.linkeddatapronom.nationalarchives.gov.uk/

vocabulary/pronom-vocabulary.htm

Nome: VMAP MusicEntity TypeDefinição: n/aURI: http://purl.org/NET/vmap/entityTypeVer: n/a



http://www.agls.gov.au/documents/agls-document/

http://www.agls.gov.au/documents/AglsJuri/

http://www.agls.gov.au/documents/agls-audience/

http://test.linkeddatapronom.nationalarchives.gov.uk/vocabulary/pronom-vocabular y.htm

http://test.linkeddatapronom.nationalarchives.gov.uk/vocabulary/pronom-vocabular y.htm


Continuação

Nome: VMAP MusicalFormTypeDefinição: n/aURI: http://purl.org/net/vmap/musicalForm/Ver: n/a

Nome: VMAP MusicGenreTypeDefinição: n/aURI: http://purl.org/net/vmap/musicGenre/Ver: n/a

Nome: VMAP TargetedStudentDefinição: n/aURI: http://purl.org/net/vmap/targetedStudent/Ver: n/a

Nome: VMAP MusicStyleTypeDefinição: This sections defines a simple vocabulary for use within the

vmap:musicStyle property in the Variazioni Musical Application Profile.URI: http://purl.org/net/vmap/musicGenre/Ver: n/a

Nome: VMAP TonalityDefinição: n/aURI: http://purl.org/net/vmap/tonalityTypeVer: n/a

Nome: VMAP rhythmTypeDefinição: n/aURI: http://purl.org/net/vmap/rhythmType/Ver: n/a

Nome: VMAP scoreTypeDefinição: n/aURI: http://purl.org/net/scoreType/Ver: n/a

Nome: VMAP documentTypeDefinição: n/a




Continuação

URI: http://purl.org/net/documentType/Ver: n/a

Nome: VMAP learningModalityDefinição: n/aURI: http://purl.org/net/learningModalityVer: n/a

Nome: VMAP classTypeDefinição: n/aURI: http://purl.org/net/classtype/Ver: n/a

Nome: VMAP educationLevelTypeDefinição: n/aURI: http://purl.org/net/educationLevelTypeVer: n/a

Nome: VMAP conferenceTypeDefinição: n/aURI: http://purl.org/net/conferenceType/Ver: n/a

Nome: VMAP conferenceTopicDefinição: n/aURI: http://purl.org/net/conferenceTopic/Ver: n/a

Nome: VMAP musicPerformance TtypeDefinição: n/aURI: http://purl.org/net/musicPerformanceType/Ver: n/a

Nome: VMAP productionTypeDefinição: n/aURI: http://purl.org/net/vmap/productionType/Ver: n/a




Continuação

Nome: VMAP sourceFormatTypeDefinição: n/aURI: http://purl.org/net/vmap/sourceFormatType/Ver: n/a

Nome: VMAP colorTypeDefinição: n/aURI: http://purl.org/net/vmap/colorType/Ver: n/a

Nome: VMAP directionTypeDefinição: n/aURI: http://purl.org/net/directionType/Ver: n/a

Nome: VMAP conservationStateTypeDefinição: n/aURI: http://purl.org/net/consertvationStateType/Ver: n/a

Nome: VMAP scoreFormatTypeDefinição: n/aURI: http://purl.org/net/musicalFormatType/Ver: n/a

Nome: VMAP keyTypeDefinição: n/aURI: http://purl.org/net/keyTypeVer: n/a

Nome: VMAP keyModeTypeDefinição: n/aURI: http://purl.org/net/keyModeType/Ver: n/a

Nome: VMAP recordStatusTypeDefinição: n/aURI: http://purl.org/net/recordStatusType




Continuação

Ver: n/a

Nome: Eprint Entity Type VocabularyDefinição: A list of types used to indicate an entity in the Eprints Model.URI: http://purl.org/eprint/terms/EntityType/#

Ver: http://purl.org/eprint/entityType/

Nome: Eprint Access RightsDefinição: A list of terms used to indicate access rights to a copy of an eprint.URI: http://purl.org/eprint/terms/AccessRights/#Ver: http://purl.org/eprint/accessRights/

Nome: Eprint StatusDefinição: A list of terms used to indicate the peer-reviewed status of an expression

of an eprint.URI: http://purl.org/eprint/terms/Status/#Ver: http://purl.org/eprint/status/

Nome: Eprint TypeDefinição: A list of types used to categorize the nature or genre of an expression of

an eprint.URI: http://purl.org/eprint/terms/Type/#Ver: http://purl.org/eprint/type/

Nome: Darwin Core Type VocabularyDefinição: The Darwin Core Type Vocabulary extends the DCMI Type Vocabu-

lary and provides a list of approved values that may be used for thebasisOfRecord term to identify the specific type of a resource

URI: http://rs.tdwg.org/dwc/terms/type-vocabulary/Ver: n/a

Nome: AGROVOCContinua na página seguinte...


http://purl.org/eprint/entityType/

http://purl.org/eprint/accessRights/

http://purl.org/eprint/status/

http://purl.org/eprint/type/


Continuação

Definição: AGROVOC is a multilingual structured thesaurus of all subject fields inagriculture, forestry, fisheries, food and related domains (e.g. environ-ment). It consists of words or expressions (terms), in different languagesand organized in relationships (e.g. broader, narrower and related),used to identify or search resources. Its main role is to standardize theindexing process in order to make searching simpler and more efficient,and to provide the user with the most relevant resources.

URI: http://aims.fao.org/aos/agrovocVer: http://aims.fao.org/standards/agrovoc/linked-open-data

Nome: Thesaurus for the Social SciencesDefinição: The Thesaurus for the Social Sciences (Thesaurus Sozialwissenschaften)

is a crucial instrument for the content-oriented search by keywords inSOFIS and SOLIS. The list of keywords contains about 12,000 entries, ofwhich more than 8,000 are descriptors (authorised keywords) and about4,000 non-descriptors. Topics in all of the social science disciplines areincluded.

URI: http://lod.gesis.org/pubby/page/thesoz/concept/Ver: http://www.gesis.org/en/services/research/

thesauri-und-klassifikationen/social-science-thesaurus/

Nome: EurovocDefinição: EuroVoc is a multilingual, multidisciplinary thesaurus covering the ac-

tivities of the EU, the European Parliament in particular. It containsterms in 22 EU languages (Bulgarian, Czech, Danish, Dutch, English,Estonian, Finnish, French, German, Greek, Hungarian, Italian, Latvian,Lithuanian, Maltese, Polish, Portuguese, Romanian, Slovak, Slovenian,Spanish and Swedish), plus Croatian and Serbian. EuroVoc users includethe European Parliament, the Publications Office, national and regionalparliaments in Europe, plus national governments and private usersaround the world.

URI: http://eurovoc.europa.eu/schema#Ver: http://eurovoc.europa.eu/drupal/

Nome: The National Agricultural Library’s Agricultural ThesaurusDefinição: The Thesaurus and Glossary are online vocabulary tools of agricultural

terms in English and Spanish.URI: http://lod.nal.usda.gov/nalt/



http://aims.fao.org/standards/agrovoc/linked-open-data

http://www.gesis.org/en/services/research/thesauri-und-klassifikationen/social-s cience-thesaurus/

http://www.gesis.org/en/services/research/thesauri-und-klassifikationen/social-s cience-thesaurus/

http://eurovoc.europa.eu/drupal/


Continuação

Ver: http://agclass.nal.usda.gov/

Nome: STW Thesaurus for EconomicsDefinição: The thesaurus provides vocabulary on any economic subject: more than

6,000 standardized subject headings and about 19,000 entry terms tosupport individual keywords. You can also find technical terms used inlaw, sociology, or politics, and geographic names.

URI: http://zbw.eu/stw/descriptor/Ver: http://zbw.eu/stw/versions/latest/about

Nome: DBPEDIADefinição: DBpedia is a community effort to extract structured information from

Wikipedia and to make this information available on the Web. DBpediaallows you to ask sophisticated queries against Wikipedia, and to linkother data sets on the Web to Wikipedia data. We hope this will makeit easier for the amazing amount of information in Wikipedia to be usedin new and interesting ways, and that it might inspire new mechanismsfor navigating, linking and improving the encyclopedia itself.

URI: http://dbpedia.org/page/Ver: http://dbpedia.org

Nome: CC RELDefinição: The Creative Commons Rights Expression Language (CC REL) is a

specification describing how license information may be described usingRDF and how license information may be attached to works.

URI: http://creativecommons.org/nsVer: http://wiki.creativecommons.org/CC_REL

Ver: http://creativecommons.org/schema.rdf

Nome: ISA core location vocabularyDefinição: The Core Location Vocabulary is a simplified, reusable and extensible

data model that captures the fundamental characteristics of a location,represented as an address, a geographic name, or a geometry.

URI: http://example.org/ns/locn#Ver: https://joinup.ec.europa.eu/asset/core_location/aescription

Nome: ISA core person vocabularyContinua na página seguinte...


http://agclass.nal.usda.gov/

http://zbw.eu/stw/versions/latest/about

http://dbpedia.org

http://wiki.creativecommons.org/CC_REL

http://creativecommons.org/schema.rdf

https://joinup.ec.europa.eu/asset/core_location/aescription


Continuação

Definição: The Core Person Vocabulary is a simplified, reusable and extensible datamodel that captures the fundamental characteristics of a person, e.g. thename, the gender, the date of birth, the location, ...

URI: http://example.org/ns/person#Ver: https://joinup.ec.europa.eu/asset/core_person/aescription

Nome: ISA core business vocabularyDefinição: The Core Business Vocabulary is a simplified, reusable and extensible

data model that captures the fundamental characteristics of a legal entity,e.g. the legal name, the activity, address, ...

URI: http://example.org/ns/legal#Ver: https://joinup.ec.europa.eu/asset/core_business/description

Nome: Dublin Core Collection Description Accrual Method Vocabu-lary

Definição: The Collection Description Accrual Method Vocabulary provides a set ofterms that can be used as values of the dcterms:accrualPolicy propertyin descriptions of collections.

URI: http://purl.org/cld/terms/AccrualMethodVer: http://dublincore.org/groups/collections/accrual-method/

Nome: Dublin Core Collection Description Frequency VocabularyDefinição: The Collection Description Frequency Vocabulary provides a set of terms

that can be used as values of the dcterms:accrualPeriodicity property indescriptions of collections.

URI: http://purl.org/cld/terms/FrequencyVer: http://dublincore.org/groups/collections/frequency/

Nome: Dublin Core Collection Description Accrual Policy VocabularyDefinição: The Collection Description Accrual Policy Vocabulary provides a set of

terms that can be used as values of the dcterms:accrualPolicy propertyin descriptions of collections.

URI: http://purl.org/cld/terms/AccrualPolicyVer: http://dublincore.org/groups/collections/accrual-policy/

Nome: Aquatic Ciência and Fisheries Abstracts ThesaurusContinua na página seguinte...


https://joinup.ec.europa.eu/asset/core_person/aescription

https://joinup.ec.europa.eu/asset/core_business/description

http://dublincore.org/groups/collections/accrual-method/

http://dublincore.org/groups/collections/frequency/

http://dublincore.org/groups/collections/accrual-policy/


Continuação

Definição: A controlled vocabulary of terms, especially key words, in fisheries foruse in indexing and information retrieval created by ASFA (AquaticCiências and Fisheries Abstracts)

URI: http://purl.org/agmes/1.1/ASFATVer: http://www4.fao.org/asfa/asfa.htm

Nome: BTDefinição: It is one of the most comprehensive and freely accessible biological

thesauri available online.URI: http://purl.org/agmes/1.1/BTVer: n/a

Nome: CABTDefinição: A controlled vocabulary of terms, especially keywords, in agricultural sci-

ences for use in indexing and information retrieval created and producedby CAB International.

URI: http://purl.org/agmes/1.1/CABTVer: http://www.cabi.org/cabthesaurus/

Nome: LEMB ThesaurusDefinição: Subject Headings List handled by Digital LEMB, is composed of a

standardized language that covers all the knowledge areas, consistingof principles that are worldwide accepted, and that allows a controlledvocabulary in order to analyze and recover information.

URI: http://purl.org/agmes/1.1/LEMBVer: http://sshdigital.com/english/index-2.html

Nome: NALTDefinição: A controlled vocabulary of terms, especially key words, in agricultural

sciences for use in indexing and information retrieval created by NationalAgricultural Library (NAL) of United States.

URI: http://purl.org/agmes/1.1/NALTVer: http://agclass.nal.usda.gov/agt/agt.htm

Nome: MEDITAGRIContinua na página seguinte...


http://www4.fao.org/asfa/asfa.htm

http://www.cabi.org/cabthesaurus/

http://sshdigital.com/english/index-2.html

http://agclass.nal.usda.gov/agt/agt.htm


Continuação

Definição: Pour décrire le contenu de ses documents, le Centre de documentationde l’IAM utilise en priorité Agrovoc, thesaurus agricole multilinguede la FAO (http://www.fao.org/agrovoc), qui représente environ 70% des termes utilisés. Les 30 % restants sont des mots-clés dans ledomaine politique, économique et dans celui de l’éducation qui ne sontpas disponibles dans Agrovoc.

URI: http://purl.org/agmes/1.1/MEDITAGRIVer: http://www.iamm.fr/baseisis/aide/thesaurus.html

Nome: UNBIS ThesaurusDefinição: The multilingual UNBIS Thesaurus, created by the Dag Hammarskjöld

Library, United Nations Department of Public Information, contains theterminology used in subject analysis of documents and other materialsrelevant to United Nations programmes and activities. It is used asthe subject authority of the United Nations Bibliographic InformationSystem (UNBIS).

URI: http://purl.org/agmes/1.1/UNBISVer: http://aims.fao.org/standards/agmes/lib-thesaurus.un.org/

Nome: AGRIS Subject CategoriesDefinição: AGRIS Subject Categories are subject categories for indexing of agricul-

tural resources developed and maintained by FAO.URI: http://purl.org/agmes/1.1/ASCVer: http://aims.fao.org/website/Browse-Classification-Schemes/

sub

Nome: ASFAC Classification SchemeDefinição: It is used to broadly categorise the subject areas of work of the various

organizations in the ASFA Directory.URI: http://purl.org/agmes/1.1/ASFACVer: http://www.fao.org/documents/show_cdr.asp?url_file=/DOCREP/

005/Y2810B/y2810b0g.htm

Nome: CABI CodesDefinição: CABI Codes are the main subject headings derived from the classifica-

tion schemes used in the AGRICOLA and AGRIS databases, to groupresources in to a specific subject maintained by CAB International.

URI: http://purl.org/agmes/1.1/ASCContinua na página seguinte...


http://www.fao.org/agrovoc

http://www.iamm.fr/baseisis/aide/thesaurus.html

http://aims.fao.org/standards/agmes/lib-thesaurus.un.org/

http://aims.fao.org/website/Browse-Classification-Schemes/sub

http://aims.fao.org/website/Browse-Classification-Schemes/sub

http://www.fao.org/documents/show_cdr.asp?url_file=/DOCREP/005/Y2810B/y2810b0g .htm

http://www.fao.org/documents/show_cdr.asp?url_file=/DOCREP/005/Y2810B/y2810b0g .htm


Continuação

Ver: n/a

Nome: Global Forest Decimal Classification (GFDC)Definição: The Global Forest Decimal Classification created by IUFRO a dynamic,

open, user-driven international community of individuals involved inforest-related research committed to improving access to forestry andforest-related information by maintaining, enhancing and applying aflexible, multilingual, hierarchical, controlled subject classification.

URI: http://purl.org/agmes/1.1/GFDCVer: http://www.iufro.org/

Nome: FAO Technical Knowledge Classification SchemeDefinição: The FAO Technical Knowledge Classification Scheme was established as

part of the development of the FAO Knowledge Forum. This classificationwas created with the purpose of mapping FAO staff technical expertiseand FAO activities.

URI: http://purl.org/agmes/1.1/FTKCSVer: n/a

Nome: Journal of Economic Literature - Classification systemDefinição: n/aURI: http://purl.org/agmes/1.1/JELVer: http://www.aeaweb.org/journal/jel_class_system.php

Nome: Accession NumberDefinição: Accession Number is a unique number assigned to each record in a

database or at an organization. Accession number should always beaccompanied by the holding place information.

URI: http://purl.org/agmes/1.1/ANVer: n/a

Nome: Call NumberDefinição: n/aURI: http://purl.org/agmes/1.1/CNVer: n/a

Nome: CODENContinua na página seguinte...


http://www.iufro.org/

http://www.aeaweb.org/journal/jel_class_system.php


Continuação

Definição: A system of alphanumeric codes developed by the American Society forTesting and Materials (ASTM ) to uniquely and permanently identifysci-tech serial and monographic publications. Responsibility for adminis-tering the system was transferred to Chemical Abstracts Service (CAS)in 1975. The CODEN is used in electronic information systems to processbibliographic data because it is more concise than the full title and lessambiguous than an abbreviated title.

URI: http://purl.org/agmes/1.1/CODENVer: http://www.issn.org/

Nome: DOIDefinição: A system for identifying content objects in the digital environment. DOIs

are names assigned to any entity for use on digital networks.URI: http://purl.org/agmes/1.1/DOIVer: http://www.doi.org/

Nome: International Patent ClassificationDefinição: A code assigned to a patent or patent-like document by many national

industrial property offices and is identified by WIPO/INID Code 51.URI: http://purl.org/agmes/1.1/IPCVer: http://www.iso.ch/iso/en/CatalogueDetailPage.

CatalogueDetail?CSNUMBER=4084

Nome: International Standard Book Number - ISBNDefinição: International Standard Book Number. The ISBN is a unique machi-

ne-readable identification number used to uniquely mark a book. 145countries and territories are officially ISBN members.

URI: http://purl.org/agmes/1.1/ISBNVer: http://www.isbn.org/

Nome: International Standards Serial Number - ISSNDefinição: It is an eight-digit number which identifies periodical publications as

such, including electronic serials.URI: http://purl.org/agmes/1.1/ISSNVer: http://www.issn.org/

Nome: Linking International Standards Serial Number - ISSN-LContinua na página seguinte...


http://www.issn.org/

http://www.doi.org/

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=4084


http://www.isbn.org/



Continuação

Definição: A specific ISSN, designated to enable collocation or linking between thesedifferent medium versions.

URI: http://purl.org/agmes/1.1/ISSN-LVer: http://www.issn.org/

Nome: Job NumberDefinição: Number allotted to a resource for purposes of identification and retrieval.URI: http://purl.org/agmes/1.1/JNVer: n/a

Nome: Microfiche NumberDefinição: Microfiche Number is a unique number identifying a microfiche, i.e.

document photographed in reduced size for viewing on projector.URI: http://purl.org/agmes/1.1/MNVer: n/a

Nome: Patent NumberDefinição: The format of this field consists of the following parts: name of the

country in which the document is issued, phrase patent document, patentnumber, /WIPO letter code.

URI: http://purl.org/agmes/1.1/PNVer: http://www.iso.ch/iso/en/CatalogueDetailPage.

CatalogueDetail?CSNUMBER=4084

Nome: Report NumberDefinição: A number uniquely identifying a report. A report is a formal statement

of the results of an investigation, proceedings at a meeting, or of anyoccurrence, event or matter on which definite information is required.

URI: http://purl.org/agmes/1.1/RNVer: n/a

Nome: UK Educational Levels – UKELDefinição: The UK Educational Levels (UKEL) list provides a set of high-level

terms to name educational levels across all UK educational sectors.URI: http://purl.org/meg/terms/Ver: http://www.ukoln.ac.uk/metadata/education/ukel/

Nome: FRAD User TasksContinua na página seguinte...





http://www.ukoln.ac.uk/metadata/education/ukel/


Continuação

Definição: Functional Requirements for Authority Data User Tasks.URI: http://iflastandards.info/ns/fr/frad/fradusertaskVer: http://www.ifla.org/publications/functional-requirements-for-bibliographic-records

Nome: FRBRer User TasksDefinição: Functional Requirements for Bibliographic Records User Tasks.URI: http://iflastandards.info/ns/fr/frbr/frbrer/frbrerusertaskVer: http://www.ifla.org/files/cataloguing/frbr/frbr_2008.pdf

Nome: FRSAD User TasksDefinição: Functional Requirements for Subject Authority Data User Tasks.URI: http://iflastandards.info/ns/fr/frsad/frsadusertaskVer: http://www.ifla.org/files/classification-and-indexing/

functional-requirements-for-subject-authority-data/

frsad-final-report.pdf

Nome: Info-eu-repoDefinição: Publication TypesURI: http://purl.org/info:eu-repo/Ver: http://wiki.surf.nl/display/standards/info-eu-repo

Nome: DC2AP Type VocabularyDefinição: The set of classes specified by the DC2AP Type Vocabulary, used to

categorize the nature or genre of the resource.URI: http://purl.org/dc2ap/ves/typeVer: n/aNome: DC2AP Format VocabularyDefinição: The set of file formats specified by the DC2AP Format Vocabulary, used

to categorize the nature or genre of the files.URI: http://purl.org/dc2ap/ves/formatVer: n/aNome: Open Metadata Registry Status VocabularyDefinição: n/dURI: http://metadataregistry.org/uri/RegStatusVer: n/a

Tabela C.88 – Esquemas de codificação de vocabulário


http://www.ifla.org/publications/functional-requirements-for-bibliographic-recor ds

http://www.ifla.org/files/cataloguing/frbr/frbr_2008.pdf




http://wiki.surf.nl/display/standards/info-eu-repo

Apêndice D

Guião das entrevistas adesenvolvedores Dublin CoreApplication Profile

349

Information Systems DepartmentUniversity of Minho, Portugal

http://www.dsi.uminho.pt

PhD researcher - Mariana MaltaContributing to a methodology for DCAP development

Interview to DCAP developer

1 Regarding the whole process of the DCAP development 1.1 Did you use any methodology1? Any process theory ? Which? 1.2 Was it a linear process, or did you have any kind of iteration, re-feed process? Could

you describe it, or give any documents that you might have developed during theDCAP development describing it?

1.3 How was the working group composition ? What were the skills of each member? 1.4 What kind of software tools did you use to develop the process?

2 Regarding the initial phase (definition of DCAP scope) 2.1 What documents did you developed - besides the obligatory Functional Requirements

(FR) document - to define the scope? Can you provide me with those documents? 2.2 What techniques/dynamics/methodology did you use to define those documents?

3 Regarding the domain model development phase 3.1 Did you have some intermediary phases before arriving to a Domain Model (DM) (ex:

did you build a conceptual model) ? 3.2 What techniques did you use to arrive to a DM ? Could you describe them? 3.3 Which data representation modeling did you use (ex: UML, ER)? How did you justify

your choice?

4 Regarding the Metadata schemes and controlled vocabularies definition 4.1 How was the process of choosing a specific element of a metadata scheme for a

particular attribute of the DM? Could you describe it? 4.2 Did you create any new controlled vocabulary? 4.3 (If you answered yes to the 4.2 question) Did you use any specific technique to create

the new controlled vocabulary? Could you describe it?

1 By methodology we mean a body of operations to achieve a goal. A methodology shows how to operationalize defined steps

Contributing to a methodology for DCAP development | Mariana Malta | Dec 2012 | Interviews to DCAP developers V1.0

Apêndice E

Base de conhecimento utilizada paraa concepção do Method for theDevelopment of Dubin CoreApplication Profiles

As Figuras E.1 e E.2 apresentam o caminho percorrido na construção do Me4DCAP. Elas apre-sentam as bases de conhecimento que foram usadas para construir as duas versões intermédias.

351

E. Base de conhecimento utilizada para a concepção do Method for the Development of Dubin Core ApplicationProfiles



Figura E.1: Base de conhecimento utilizada para a definição de Method for the Development of Dubin Core Application Profiles V0.1



Figura E.2: Base de conhecimento utilizada para a definição de Method for the Development of Dubin Core Application Profiles V0.2


Apêndice F

Grupo de discussão de validação doMethod for the Development ofDubin Core Application ProfilesV0.1

F.1 Introdução

A sessão realizou-se oficialmente das 13h30 às 14h30 no auditório J.1610; apresentámos a versão0.1 do método1 durante 45 minutos e nos restantes 25 minutos dialogámos com os presentes.Participaram cerca de 10 pessoas. A sessão foi gravada em audio para posterior tratamento.

F.2 Transcrição

Apresentamos a discussão que aconteceu após a apresentação do Me4DCAP V0.1. A discussão édescrita de forma que cada interpelação/pergunta transcrita é apresentada seguida da discussãoque gerou. As respostas às interpelações estão em itálico e foram efectuadas por Mariana Maltae Ana Alice Baptista.

1. There are so many metadata schemes around, and basically what we are always trying todo - we try to avoid to re-invent the wheel, I know there is a nice graphic on the Web withall metadata standards and it is a huge galaxy, so basically the risk I see is, when you say,OK I invented this for the what was it, the “salary”? The question is: is there really not anattribute out there which maps this? So basically it depends a little bit on the knowledgeof the guy who designs it and this is really an issue, if you do not know there is an attributeout there then you invent again your own things and you end up OK everybody defines itsown “salary” and then you break interoperability which you basically desire. So I am not

1c.f. Curado Malta & Baptista (2013b)

357

F. Grupo de discussão de validação do Method for the Development of Dubin Core Application Profiles V0.1

quite sure but would be some sort of metadata catalog where you can say OK do I havethe complete picture of it? Can I somehow look what is out there already?

• there are these metadata registers were you can look for other elements and alsovocabularies that are defined and so on, that’s always a good way to start.

2. If I define my own “salary”, and someone says “Hey guys! There is all ready a salary outthere”. Can I re-use the process and update my metadata to use this new attribute which isalready out there? Would I add it to the scheme or would I replace it? - I mean if I replaceit I might break the consistency with systems already built on my scheme, developed sofar...

• regarding this would be to do a match at schema level I would not change my metadata,I would do a match for instance using SKOS with a “related match” or “close match”they have these properties in SKOS where you can, you have different schemas andthen you can say: OK I have this property here that is “salary” - whatever - and Ifind another scheme, I didn’t find this property before but I have found it now and Iwant to say that this one is the same as that one or that this one is a sub-propertyof that other one, or that is more general than the other one. You can define severalkinds of relationships between different properties and different schemas.

• Some sort of ontology alignment?

• You can do these without using - you can call it ontology alignment - but we use SKOSvery much because it is more simple than OWL, you have these properties that relateschemas and that relate vocabularies and well is a W3C recommendation safe to use.

3. I am bit confuse but maybe because I am an ignorant of this issue. Your main objective isto define, you call it a “formal method”. So mine addition maybe I would like to understandwhat is the “formal” in there. But OK, you want to define a formal method and thatdoesn’t exist yet. What is the Singapore Framework (SF)? I don’t understand what is theSingapore in there?

• That is a very good question. Is the Singapore Framework a method? Thee methodfor this? No! The Singapore Framework defines what is a Dublin Core ApplicationProfile, like OK you have the Functional Requirements but they don’t say how you,how do I, what is the process of building all that!

• Well you have methods in the Software Engineer...

• Yes..

• ...that can, maybe can apply, so this is the part ....

• Yeah that was my source but I didn’t explain that but I can say that to build thismethod I didn’t just came here and say: OK! No - let me just bring some slides - Iwent to another conference where I exactly explained the research methodology, and in



the research methodology - it is always the same actually in any research project, youhave to do a State of the Art, isn’t it? And that what you are talking is that we haveto do a State of the Art and my State of the Art was: let’s see i am going to builda method, a method that has data modeling, well in SE we also have the phases ofdata modeling, so what did I do, I went to look for methods to develop software and Idecided to start, as a base to have Rational Unified Process, so if you know about SE Iam sure that you recognize this.

• YES! (YES...)

• OK? This was my starting point. And you say: but why the Rational Unified Processand not another one?

• Extreme programing, Agile methods?

• Exactly. They also have a little bit of these (:::) Probably you know much more thanme about this but.... You have to start from somewhere and we decided for Rationalbecause it has many years of maturity many people using it so it’s not an immatureprocess. But it was very interesting on my talk, on Monday (refere-se à sessão doDoctoral Consortium) one of the feedbacks of the expert was: OK that is interestingthat you started with RUP but you know RUP is so old! And you have other this,e.g. methods for ontologies, methods for Information Systems - not software - butInformation Systems, and he said other things and actually my main source was RUP(I don’t know how you say it in English but in Portuguese you say RUP “R” “U”“P”) but also I made a the state of the art, a literature review and I have found amethod for Ontologies (METHONTOLGY) with lots of citations and other methodslike, but a method that actually - it is a German guy - that is against RUP, I haveread those methods and in the end I joined all the information OK? and I came tothis conclusion so it is not like I was (:::). And also I interviewed 4 Dublin CoreApplication Profile developers where they talked about the experience of developingtheir Dublin Core Application Profile and also I took information. And again as AnaAlice said, this is a first approach and it is not thee method and it is not a prescriptionthat everyone should follow, no, it is OK, we offer this as my work, if it is valid, Iam happy, and I really want it to be used to test and to start a new way to define amethod.

• My impression is maybe it would be a little bit more clear about this “top???” itemswhich is the “formal method” and the running example you have - the craftsmancatalog - so because this things the language is the same, sometimes the language isthe same, a language that describes the method ....

• because you are referring to the “formal”, you are meaning with the mathematicalbasis

• I don’t know she said: “It is a formal method” and there are some “formal methods”!

• Oh, that is interesting, you don’t like the word “formal”, OK! What would you call it?A Method?



• I don’t know Rational what uses Rational calls?

• Rational Unified Process, they call it a process, not a method actually.

• YES. Yeah....but.....it’s....

• You could call it a work flow

• It is like vocabularies, ontologies and ???? it is all the same but.....I just felt somebetter separation of this, I think that is difficult but to explain the method and havethe running example, clearly identified as a running example that and that maybethat comes after you introduce your method, at each phase, well you did I like that.

• But I have to elaborate more.....

• Could help clarify a color for the method a different color for the running example, ora different font.

4. It is also related with the, with the part of the method, in the domain model. I think thereare two aspects of Dublin Core Application Profile which may influence which method isbest. One is that the Application Profiles are usually built in heterogeneous groups whichare spread (may not meet physically together) if you take that into account ...

• That is something I didn’t mention but on the method I have a little section saying thatwe should use collaborative tools and I give examples because actually what to definethis method I am also building a Dublin Core Application Profile with a communityand they are in Brazil, Canada, so we have to work together, so we have. We had tofind tools in order to share information

• I think he is meaning more than that

• That is not the question?

• He is meaning more than that. You are meaning more than that, because when you usea SE method you are working inside the walls of an organization and here everythingis open and you have to count on that. That is what makes the difference from buildingthis domain model or building this what you call it a Dublin Core Application Profilefrom building a domain model from a controlled scenario that is an organization. Yesit is foreseen in your method....We talked about this a thousand times. This issue ofinteroperability is...yeah.

5. I also have another related question. There are specific ways to ah...or there are somespecificities of modeling ontologies for the Semantic Web, the structure ?? it is a bitdifferent from...so I was wondering if this methodology if it would fit or in the end youwould end up with having to do something additional to change your domain model intosomething that is more suitable for an ontology.

• It is not in our scope we define Application Profile so we don’t go...the idea of...

• To design an Ontology from an Application Profile



• That is another thing...

• To design an ontology from an Application Profile - there will be a very nice discussionin DC 2013 in Lisbon, about that, about Application Profile and ontologies, there willbe a special session on that theme, I think will be very interesting.

• Actually when I define the objects I have to define the classes, there are classes ofobjects, so I looked for classes to identify that object.

• You use UML class diagrams for this?

• Yeah but not really deep. Just to say that we identify the class, but we don’t go further,we stop there. In an ontology you can relate classes, you go further. But there no, westop there. And it is not in the scope of the method to define how to go further andtransform, no .....

• But my question was: How could this affect the decision on what is the best approachto the domain model, or designing the domain model....

• No, I didn’t understand, what is “this” ?

• If the outcome is to have an ontology in the end, ???? requirements for, would itaffect the methodology that you would choose for the domain model.

• The domain model would be more elaborated. Definitely. I would have to, I wouldhave to, how do you say?, go deeper on the many to many relation, yeah, and pricewould appear there. Yes

• More elaborated than this model...?

• Yes, for an ontology

• ...but then you would have ORM to go deep as well.

• But the domain model, may be may be, something that occurred me, but I didn’t do itbecause everyone I interviewed used UML or E-R, I didn’t want to go so, I didn’t wantto be completely disruptive (..) I would say we don’t need UML, we could go directlyORM.

• YES!

• But everyone was doing like that even DC Guidelines.

• Yeah but i think we could skip UML.

• What is ORM?

• ORM is Object Role Modeling - role centered.

• I think UML class diagram is doing some noise.

• Now we have like that, it is first version, but probably on the second version...

• We take it out!

F.3 Email convite


Assunto: Contribution and feedback for the session Me4DCAP V0.1: Metadata -Elpub friday sessionDe: Peter Linde <[email protected]>Data: 13-06-2013 17:27Para: undisclosed-recipients:;

Dear attendee,

Tomorrow morning, in the 09:00-10:30 session, we will be presenting the paper "Me4DCAP V0.1: A method for thedevelopment of Dublin Core Application Profiles". An application profile is a generic construct for designingmetadata records.

The Me4DCAP method is being developed using the Design Science Research (DSR) methodology. One of the DSRsteps is Evaluation. We are now starting this phase in our research work. Therefore, in the afternoon, at13:30, we will be running the special session "Me4DCAP V0.1: Metadata", which is related to this evaluationphase. The main goal is to have feedback from people interested in designing metadata and applicationprofiles regarding Me4DCAP.

If you are interested in metadata and want to contribute with your expertise and experience to the evaluationof Me4DCAP, we thank your presence at least in the afternoon session and appreciate your contribution andfeedback.

Thank you in advance,

Mariana Malta and Ana Alice Baptista

Portugal

Peter LindeBlekinge Tekniska HögskolaBiblioteket371 79 KarlskronaTel 0455-385103, Fax 0455-385107Mobile: +46 708 778138E-mail: [email protected]

Blekinge Institute of TechnologyThe LibraryS-371 79 KarlskronaSwedenTel +46 455 385103Fax +46 455 385107E-mail: [email protected]

Contribution and feedback for the session Me4D...

1 de 1 22-10-2013 16:29

Apêndice G

Focus Group de validação do Methodfor the Development of Dubin CoreApplication Profiles V0.2

G.1 Definição do Focus Group

Foram seleccionados participantes:• tendo como base a sua experiência de trabalho: especialistas de metadados, trabalhandoem projectos que envolvessem a criação de perfis de aplicação, vocabulários controlados,ou a definição de modelos de dados na WS, ou outros projectos em variados contextosrelacionados com a WS;

• tendo em atenção a sua formação académica, possuindo pelo menos um mestrado;• de forma a obter um grupo heterogéneo em termos de nacionalidade e em termos de género.Este último ponto não se concretizou porque não conseguimos mais do que um elementodo sexo feminino.

O número de participantes a seleccionar seria entre 6 e 8 pessoas1, uma vez que segundoKrueger and Casey (2000) este é o número ideal de um FG.

Para reunirmos os participantes necessários enviamos um email convite (ver Secção G.2) a umconjunto de pessoas que sabiamos que estariam na conferência DC-20132. Esse email foi enviadoa 31 de Julho de 2013, 5 semanas antes do início da conferência. Algumas pessoas responderamao email, mas não em número suficiente para realizar o FG. Decidimos que iriamos contactarpessoalmente outras pessoas que estivessem dentro dos nossos critérios de selecção, já durante aconferência, logo nos primeiros dias. Conseguimos reunir 7 pessoas.

Duas semanas antes da sessão foi enviado um email com o artigo a discussão (Curado Maltaand Baptista (2013c)) de forma a que os participantes pudessem preparar-se para a sessão. Aosparticipantes seleccionados na própria conferência foi-lhes pedido que estivessam na sessão de

1No email convite - c.f. G.2 - referimos que o número de participantes entre 7 e 9 mas de facto iriamosseleccionar um valor entre 6 e 8.

2De 2 a 6 de Setembro de 2013, Instituto Superior Técnico, Lisboa, Portugal

363

G. Focus Group de validação do Method for the Development of Dubin Core Application Profiles V0.2

apresentação do artigo.O FG foi realizado num momento de pausa da conferência, nas instalações do INESC-ID em

Lisboa, no dia 5 de Setembro de 2013 entre as 16h50 e as 18h30 (um momento acordado entretodos os participantes que responderam positivamente ao email convite).

A sessão foi gravada em vídeo, com duas câmaras, de forma a obtermos a recolha de duasfontes de dados; caso uma falhasse haveria a segurança dos dados da outra fonte. Além disso,foram analisadas as duas fontes de dados para nos assegurarmos de que toda a informação erarecolhida - em alguns casos, devido ao sotaque e dicção de determinados participantes, era difícila compreensão do discurso. Foi assegurado aos participantes que a gravação seria unicamenteutilizada para fins de investigação, que a sessão não seria tornada pública, e que as discussõesaí realizadas não seriam transcritas na íntegra, mas somente as suas conclusões. Todos osparticipantes deram verbalmente autorização para serem filmados.

A moderação da sessão foi realizada por Mariana Malta e o relator foi Ana Alice Baptista.As mesas foram colocadas em U e os participantes sentaram-se de modo a ficarem em frente àscamâras. Distribuimos pelos participantes, no início da sessão, uma ficha de contacto para quecada um preenchesse os seus dados socio-demográficos e profissionais, e ainda uma folha com aFIG. 3 “Me4DCAP V0.2 life-cycle development model” do artigo apresentado na conferênciaDC-2013 com a versão V0.2 (c.f. Curado Malta and Baptista (2013c) - pag. 94)3

A sessão desenrolou-se da seguinte forma:1. Os participantes preencheram a ficha de contacto;2. Explicámos o objectivo da sessão e apresentámos a organização da sessão;3. Apresentámos o Me4DCAP V0.2;4. Colocámos um conjunto de perguntas ao grupo. A cada pergunta, os participantes foram

dando a sua opinião, de uma forma aleatória, sem ordem definida de intervenção. Osparticipantes puderam dialogar entre si livremente. As perguntas foram:

(a) Relativamente à equipe de trabalho - o que tem a dizer?

(b) Relativamente ao ciclo de vida, com os seus vários blocos e deliverables, o que tem adizer?

(c) Relativamente a “nome do deliverable”, o que tem a dizer? (esta questão foi desdobradaem tantas quantas os deliverables definidos à excepção de deliverable “validação emprodução“.

(d) Relativamente à ”validação em produção“, como poderá ser melhorada?

5. Os participantes preencheram o inquérito (ver secção G.3).A informação do inquérito acabou por não ser alvo de uma análise quantitativa dado que a

amostra era demasiado pequena.

G.2 Documento convite

3Esta imagem é a mesma apresentada na Figura 4.9b do capítulo 4, mas na sua versão em inglês.


On Wed, Jul 31, 2013 at 10:45:22PM +0100, Ana Alice Baptista wrote:

>> Mariana Malta, a PhD student of mine, has been working on the development of>> a method for the development of Dublin Core Application Profiles (DCAP) under>> a software engineering perspective (1). We are now starting the validation>> phase of Me4DCAP with two Focus Groups sessions. >> >> Taking advantage of the presence of metadata community experts at DC2013, we>> intend to do the first Focus Group session during the conference time with a>> limited number attendees - ideally, 7 to 9. The session will take place at>> Day 1 (Tuesday) at 16h30 in a room to be defined, and will last for 1h30. It>> will start with the presentation of Me4DCAP, followed by a moment of>> question/answers to a set of questions previously defined, and will end with>> the filling of a questionnaire. >> >> We would be very pleased and honoured with your presence in this Focus Group>> session since your are one of the most authoritative experts that would>> surely help us to improve Me4DCAP.>> >> Looking forward for a positive answer from your side, I send you my best>> regards.>> >> Ana Alice Baptista>> >> (1) See the abstract of the paper Mariana will present on day 2 (Wednesday):>> http://dcevents.dublincore.org/IntConf/index/pages/view/2013-peerAbstracts#Malta

Fwd: DC-2013 - Validation of Me4DCAP - Invitation

1 de 1 22-10-2013 16:26

G. Focus Group de validação do Method for the Development of Dubin Core Application Profiles V0.2

G.3 Inquérito

Na página seguinte apresentamos o inquérito que foi distribuído aos participantes no final dasessão.


1

1 2 3 4 51 The method 's description is clear3 The method's phases definition is clear2 The method's life-cycle development model is clear4 The method's work-team definition is clear

5 A DCAP development becomes too complex if we follow this method

6

2

1 2 3 4 51 The constitution of the team is perfect2 A project manager is an essential element of the team3 A system analyst is an essential element of the team4 An integrator is an essential element of the team5 A final user is an essential element of the team

6

7 There are profile type(s) missing on the work-team

8 If yes, which?

3

1 2 3 4 5134

5 If yes, which?

4

1 2 3 4 5

1

2

3 The Vision Statement deliverable development technique is clear

4

5

Me4DCAP - Validation ProcessFocus Groups - Questionnaire

Please answer the following questions according to your degree of agreement with the statements

(1 - Very little; 2 - Little; 3 - Medium; 4 - Very; 5 - Very Much)

Me4DCAP general view

A DCAP development becomes too complex if we follow this method; but despite that, it is important to have a method

Work-team

It is perfectly clear who is responsible for which deliverable in the development process.

Life-cycle development process

The life-cycle is too complexThe order of the deliverables is not the idealThere are deliverables missing

Functional Requirements building process

The deliverables identified to build the Functional Requirements are the necessary and sufficient

The Vision Statement is an important deliverable

The Expression of the Functional Requirements is an important deliverableThe Expression of the Functional Requirements deliverable development technique is clear

6

7 The Use-Cases Model deliverable development technique is clear

8 The described Functional Requirements development process is clear

9

5

1 2 3 4 5

1

2

3

4

5

6 The technique used to build the Domain Model is not important

6

1 2 3 4 5

1

2 The Integration Dossier building process is well explained3 The Detailed Data Model Diagram is an important deliverable

4

5

6

7 The technique used to build the Detailed Data Model is not important

8 The State of the Art Report is an important deliverable9 Me4DCAP should suggest tools to build a State of the Art Report

10 The Document of Integration is an important deliverable

11

12 The Validation dossier building process is well explained13 The Validation Report building process is well explained14 The Validation Report is an important deliverable15 The Document of Validation building process is well explained

16

17 The Document of Validation is an important deliverable18 The Questionnaire building process is well explained19 The Questionnaire is an important deliverable20 The DSP framework should have more detailed guidelines

The Use-Cases Model is an important deliverable

The development order of the deliverables is right

Domain Model building process

The description of the Domain Model is clear

The description on how to obtain a Domain Model deilverable is clear

The UML technique is the most interesting technique to develop the Domain Model

The ER technique is the most interesting technique to develop the Domain Model

The ORM technique is the most interesting technique to develop the Domain Model

Description Set Profile building process

The deliverables identified to build the DSP are the necessary and sufficient

The UML technique is the most interesting technique to develop the Detailed Data Model

The ER technique is the most interesting technique to develop the Detailed Data Model

The ORM technique is the most interesting technique to develop the Detailed Data Model

The Document of Integration template presented is clear and well conceived

The Document of Validation template presented is clear and well conceived

7

1 2 3 4 5

1

2

8

1 2 3 4 5

1 A Validation in Production is very important2 The Validation in Production definition is well explained

3

4

5

6

7

9

Guidelines

The moment defined to start the development of the Usage Guidelines is well defined

The moment defined to start the development of the Syntax Guidelines is well defined

Validation in Production

The Validation in Production definition should be more developed, it is not complete

A log registration technique to produce a validation in production is a good technique

Observing final users is a good technique to produce a validation in production

There are other interesting techniques to do a DCAP validation in production

The impact of changes of a DCAP on the DCAP applications community can be big. DCAP changes after a validation in production should be very well planned.

Feel free to leave any comments you may find important

mariana curado malta contributo metodológico para o

Documents