Integração de dados em escala

Explore exemplos de OSLC

A união entre dados vinculados, desenvolvimento de software e ferramentas colaborativas

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Integração de dados em escala

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Integração de dados em escala

Fique ligado em conteúdos adicionais dessa série.

Você absorveu uma quantia considerável de material conceitual até agora nesta série:

Nesta parte final da série, eu mostro como essas ideias combinam-se para permitir que as informações sejam compartilhadas entre várias ferramentas interoperáveis.

" OSLC e a Linked Data Platform" apresentou o projeto OSLC, incluindo seu status, seus objetivos, seus princípios e a estrutura básica na qual a versão 3.0 se baseia. Como mencionei nessa parte, o projeto está em uma transição. A versão 3.0 representa um avanço bem radical de como a família 2.0 de especificações era projetada. Embora existam caminhos rumo à compatibilidade entre as versões, as novas especificações fornecem um ponto de partida mais promissor para aprender sobre OSLC. Mas, como as especificações da 3.0 ainda não estão concluídas, as ferramentas com suporte para 3.0 estão em falta por enquanto.

O modelo de controle do projeto também passou — de uma iniciativa liderada pela IBM para uma encabeçada pelo grupo OASIS. Essa mudança amplifica a consciência entre os estados estáveis, conforme os novos grupos de trabalho juntam as partes e avançam. Enquanto isso, quase toda a documentação existente— manuais, tutoriais, aplicativos de exemplo e guias de implementação— gira em torno dos designs do OSLC 2.0. Neste verão houve um movimento para organizar o material apresentado nos vários websites do OSLC, mas ainda há trabalho a fazer. Uma pessoa nova na comunidade ainda se perde com facilidade.

Apesar de todos esses empecilhos, estou otimista quanto ao futuro do projeto. Acredito que ele possa se desenvolver com base no sucesso que já teve, em uma nova base que simplifique e aprimore as oportunidades de integração para as tecnologias que reconhecem o OSLC. Neste artigo, eu apresento uma abordagem simplificada, por meio de alguns exemplos práticos, de como participar do espaço do OSLC — com uma inclinação para o novo rumo que o projeto está começando a tomar.

Aplicativo de amostra

A base de código Eclipse Lyo inclui suporte para várias especificações do OSLC e para Linked Data Platform.

O Projeto Eclipse Lyo foi estabelecido como a face das implementações de referência de software livre dos sistemas OSLC. Embora qualquer pessoa possa desenvolver um contêiner compatível com OSLC/LDP usando qualquer pilha, o Lyo fornece uma base reutilizável para aqueles que se interessam por um conjunto de ferramentas baseado em Java™.

Primeiro, instale o git e o Apache Maven. Também é necessário que haja uma versão do Java instalada. Em seguida, verifique o projeto Lyo a partir de seu repositório:

> git clone http://git.eclipse.org/gitroot/lyo/org.eclipse.lyo.rio.git
Cloning into 'org.eclipse.lyo.rio'...
remote: Counting objects: 3519, done.
remote: Total 3519 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3519/3519), 1.36 MiB | 152.00 KiB/s, done.
Resolving deltas: 100% (1285/1285), done.
Checking connectivity... done.

A base de código Lyo inclui suporte para várias especificações OSLC e para LDP. Ela é basicamente um trabalho em andamento, mas pode ser usada aqui para demonstrar uma quantia suficiente de ideias.

Um aplicativo de amostra que está disponível no projeto demonstra o básico dessas ideias. Antes de executar o aplicativo, é interessante editar o pom.xml para alterar a porta que ele usa, que assume 8080 como padrão. (Eu uso a porta padrão aqui, mas se você tiver alguma relação com o lado do servidor Java, algo já poderá estar usando a porta 8080.) Em seguida, inicie o servidor executando os objetivos do Maven install e jetty:run:

> cd org.eclipse.lyo.oslc.v3.sample
> mvn install jetty:run
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building OSLC 3.0 Reference Implementation 3.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...
[INFO] Started ServerConnector@600f5704{HTTP/1.1}{0.0.0.0:8080}
[INFO] Started @7288ms
[INFO] Started Jetty Server

Neste momento, o aplicativo de amostra— um simples rastreador der erro— está em execução. Ele tem um contêiner LDP implementado na porta padrão. Se eu tentar usar a porta diretamente, verei que há um aplicativo da web implementado em http://localhost:8080/oslc3. Se eu apontar o navegador para esse local, verei a página HTML mostrada em Figura 1. Se eu passar o mouse sobre o link do contêiner de erro, verei que há um contêiner LDP em http://localhost:8080/oscl3/r/bugs.

Figura 1. Página inicial do aplicativo de amostra OSLC 3.0
OSLC 3.0 sample application
OSLC 3.0 sample application

Como no último artigo, é possível interagir com o contêiner, solicitando a URL do contêiner como um recurso. A Listagem 1 mostra a solicitação e a resposta.

Lista 1. Solicitando informações sobre o contêiner
> http get http://localhost:8080/oslc3/r/bugs
 
HTTP/1.1 200 OK
Accept-Post: text/turtle,application/json,application/json
Allow: GET,HEAD,POST,OPTIONS
Cache-Control: no-cache
Content-Type: text/turtle
Date: Sat, 15 Aug 2015 02:53:32 GMT
ETag: "302493f36090f8e473289c4e5b47ee78"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Link: <http://open-services.net/ns/cm#Defect>;
   rel="http://open-services.net/ns/core#creationType"
Link: <http://localhost:8080/oslc3/Defect-shape.ttl>;
   rel="http://www.w3.org/ns/ldp#constrainedBy"
Link: <http://localhost:8080/oslc3/r/bugs/creationDialog>;
   rel="http://open-services.net/ns/core#creationDialog"
Server: Jetty(9.2.2.v20140723)
Transfer-Encoding: chunked
Vary: Accept,Prefer
 
@base <http://localhost:8080/oslc3/r/bugs> .
 
<> a <http://www.w3.org/ns/ldp#BasicContainer> ;
  <http://purl.org/dc/terms/title> "Bug Container" .

Na resposta, vemos o que pode ser feito com o contêiner e que ele é uma instância das classes Resource e BasicContainer do namespace http://www.w3.org/ns/ldp#. A resposta também inclui alguns links que ainda não discutimos:

  • http://open-services.net/ns/core#creationType: estou perplexo com esse. O intento é óbvio, mas ele não está documentado no vocabulário principal ao ser resolvido neste local. Não consigo localizar nenhuma outra referência a ele, portanto, pode ser um termo anterior ou um novo que ainda não foi documentado. Independentemente, ele informa que o tipo de coisa que deve ser criado para incluir no contêiner é http://open-services.net/ns/cm#Defect.
  • http://open-services.net/ns/core#creationDialog: esse relacionamento está definido no vocabulário principal e indica que ele "Permite que os clientes criem um recurso usando a UI". Isso será melhor explicado mais adiante.

Também vemos um novo uso do relacionamento http://www.w3.org/ns/ldp#constrainedBy que foi apresentado no artigo anterior. Aqui ele vincula a um arquivo Turtle que define a forma de um defeito.

Como você viu no primeiro artigo da série, o RDF foi projetado para suportar a suposição mundo aberto. Geralmente, ele não era indicado para restringir gráficos de dados para impingir um modelo de domínio esperado. As pessoas que vêm para a web semântica partindo de um software mais orientado à empresa, geralmente desejam a capacidade de "fechar" o mundo e validar a estrutura de um gráfico. Para ajudar a gerenciar as expectativas da integração entre ferramentas, o W3C RDF Data Shapes Working Group desenvolveu os esforços do OSLC para fazer apenas isso. Se eu solicitar o documento apontado pelo relacionamento constrainedBy, como na Listagem 2, verei o que fornecer a um Defect ao criar um. Cerca de vinte propriedades são anexadas ao Defect. O arquivo de forma é grande, portanto, eu reproduzo apenas parte dele na Listagem 2.

Lista 2. Solicitando informações sobre a forma de defeito
> http get http://localhost:8080/oslc3/Defect-shape.ttl
 
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 12621
Content-Type: text/turtle
Date: Sat, 15 Aug 2015 03:21:56 GMT
Last-Modified: Sat, 15 Aug 2015 00:38:24 GMT
Server: Jetty(9.2.2.v20140723)
 
@prefix foaf: <http://http://xmlns.com/foaf/0.1/> .
@prefix oslc_cm: <http://open-services.net/ns/cm#> .

@prefix oslc: <http://open-services.net/ns/core#> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
 
<> a oslc:ResourceShape ;
    oslc:describes oslc_cm:Defect ;
    dcterms:title "A software or product defect." ;
    dcterms:description  
       "Used by Quality Management tools to report defects in testing." ;
    oslc:property
        <#affectsPlanItem>,
        <#affectsRequirement>,
        <#attachment>,
        <#closeDate>,
        <#contributor>,
        <#created>,
        <#creator>,
        <#description>,
        <#discussedBy>,
        <#identifier>,
        <#instanceShape>,
        <#modified>,
        <#priority>,
        <#relatedChangeRequest>,
        <#severity>,
        <#shortTitle>,
        <#state>,
        <#subject>,
        <#title>,
        <#tracksChangeSet>,
        <#type>
        .
 
<#affectsPlanItem> a oslc:Property ;
    oslc:name "affectsPlanItem" ;
    oslc:occurs oslc:Zero-or-many ;
    oslc:propertyDefinition oslc_cm:affectsPlanItem ;
    oslc:representation oslc:Reference ;
    oslc:valueType oslc:Resource ;
    dcterms:description 
       "Change request affects plan item."^^rdf:XMLLiteral ;
    dcterms:title "Affects PlanItem" .
 
...

A descrição autoexplicativa, com significado semântico, da forma esperada das informações permite que um cliente forneça o conteúdo necessário e relevante para criar um novo defeito.

Os metadados sobre a primeira propriedade (affectsPlanItem) indicam que ela não é necessária, porque ela pode ocorrer zero ou mais vezes. affectsPlanItem conecta uma solicitação de mudança a um item no plano do projeto para propósitos de rastreamento. Existem propriedades semelhantes para os requisitos afetados, anexando um arquivo de mídia relacionado, quem criou o defeito e assim por diante. A descrição autoexplicativa, com significado semântico, da forma esperada das informações permite que um cliente forneça o conteúdo necessário e relevante para criar um novo defeito.

O link constrainedBy aponta para um documento Turtle que indica as propriedades que podem ser usadas para descrever um defeito. Além disso, um link http://open-services.net/ns/core#creationDialog está nos cabeçalhos de resposta do contêiner. Se eu solicitar o recurso vinculado por esse relacionamento, receberei os metadados sobre outra maneira de criar um recurso do tipo esperado por esse contêiner—, nesse caso, uma interface com o usuário, mostrada na Listagem 3—, que pode ser mostrada pelo cliente ao seu usuário. Eu vejo não apenas a altura e a largura sugeridas para a UI fornecida, mas também um título, um rótulo para anunciar sua presença e uma URL que posso solicitar para recuperar uma caixa de diálogo HTML real.

Lista 3. Solicitando informações sobre a caixa de diálogo de criação de defeito
> http get http://localhost:8080/oslc3/r/bugs/creationDialog
HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Sat, 15 Aug 2015 04:39:14 GMT
Server: Jetty(9.2.2.v20140723)
Transfer-Encoding: chunked
 
<http://localhost:8080/oslc3/r/bugs/creationDialog>
    a <http://open-services.net/ns/core#Dialog> ;
    <http://open-services.net/ns/core#dialog>
      <http://localhost:8080/oslc3/creationDialog.html> ;
    <http://open-services.net/ns/core#hintHeight> "395px" ;
    <http://open-services.net/ns/core#hintWidth> "450px" ;
    <http://open-services.net/ns/core#label> "Open Bug" ;
    <http://purl.org/dc/terms/title> "Open Bug" .

Um ponto importante aqui é que esses recursos são anunciados como úteis para potenciais clientes. O aplicativo faz algumas suposições diferentes da capacidade de consumir o Turtle e mostrar um documento HTML. Qualquer cliente possa desejar suportar uma capacidade integrada de criar novos defeitos, deverá ter todas as partes necessárias para fazer isso.

Nenhum cliente é obrigado a usar esses mecanismos. É totalmente possível desenvolver uma interface customizada com base nos metadados em uma definição de forma. Qualquer cliente que entenda o que é necessário, poderá facilmente converter os dados existentes e realizar POST de um novo defeito para o contêiner, programaticamente. No entanto, conforme mostrado na Listagem 4, é conveniente ter em mãos um formulário HTML pré-criado, principalmente, se o destino for usuários humanos, não clientes de software puro. Estou deixando de fora muitos dos detalhes sobre o que ele retorna, mas quero mostrar a estrutura principal.

Lista 4. Solicitando uma caixa de diálogo para auxiliar na criação de um novo defeito
> http get http://localhost:8080/oslc3/creationDialog.html
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 4068
Content-Type: text/html
Date: Sat, 15 Aug 2015 05:50:20 GMT
Last-Modified: Sat, 15 Aug 2015 00:38:24 GMT
Server: Jetty(9.2.2.v20140723)

<!DOCTYPE html>

...

<html lang="en">

<head>
  <meta charset="utf-8" />
  <meta name='viewport' content='width=device-width, initial-scale=1.0, user-scalable=no'>
  <title>New Bug - OSLC 3.0 Reference Implementation</title>
  <link rel="stylesheet" type="text/css" href="style/common.css">
  <link rel="stylesheet" type="text/css" href="style/dialog.css">
  <link rel="shortcut icon" href="oslc-16x16.png">
  <script type="text/javascript"
  src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
  <script type="text/javascript">
      // Our JSON-LD context for creating defects
      var context = {
          oslc_cm: "http://open-services.net/ns/cm#",
          dcterms: "http://purl.org/dc/terms/",
          Defect: "oslc_cm:Defect",
          description: "dcterms:description",
          severity: {
              "@id": "oslc_cm:severity",
              "@type": "@id"
          },
          title: "dcterms:title"
      };

      ...
      
  </script>
</head>

<body>
    <form>
        <div>
            <input id="title" type="text" class="bugInput" 
  required autofocus placeholder="Enter bug title">
            </input>
        </div>
        <div>
            <label for="severity">Severity:</label>
            <select id="severity">
                <option value="oslc_cm:Blocker">Blocker</option>
                <option value="oslc_cm:Critical">Critical</option>
                <option value="oslc_cm:Major">Major</option>
                <option value="oslc_cm:Normal" selected>Normal</option>
                <option value="oslc_cm:Minor">Minor</option>
            </select>
        </div>
        <div>
            <label for="description">Description:</label>
        </div>
        <div>
            <textarea id="description" class="bugInput descriptionTextArea"></textarea>
        </div>
        <div>
            <input type="submit" name="OK"></input>
            <button type="button" id="cancel">Cancel</button>
        </div>
    </form>
</body>
</html>

No último artigo, eu mostrei como é possível incluir recursos em um contêiner LDP por meio de HTTP direto. Obviamente, um sistema real teria protocolos de autenticação em vigor para permitir que somente determinadas pessoas fizessem isso. Nesse caso, veremos o fluxo de trabalho básico para fazer isso com o conteúdo HTML. Já mencionei como descobri o local da caixa de diálogo de criação. Inexplicavelmente, o aplicativo de amostra tem uma cópia duplicada dessa caixa de diálogo (chamada newBug.html), que ele instancia separadamente. Devo assumir que isso foi uma simples desatenção. Na maioria das circunstâncias, esse processo deve anunciar e usar o mesmo HTML para criar novos defeitos. No entanto, certamente não é inimaginável que você também possa ter uma capacidade compartilhada reutilizável e uma capacidade específica do aplicativo para esse propósito. É estranho que, nessa situação, haja duas cópias do mesmo arquivo exato.

Observe o arquivo index.html no diretório de amostras. Ele contém uma referência a js/index.js, — o código chamado quando o usuário clica no botão Abrir erro mostrado na Figura 1. A Listagem 5 mostra uma função do arquivo JavaScript que cria a caixa de diálogo e anexa-a ao contêiner como um iframe, a não ser que uma exibição pequena esteja sendo usada (e, nesse caso, ele cria uma nova janela independente, na qual os conteúdos da caixa de diálogo devem ser inseridos).

Lista 5. Mostrando a caixa de diálogo para criar um novo defeito
function showDialog() {
  if (isSmallScreen()) {
    // For small screens, open a new window.
    dialogWindow = window.open('newBug.html', 'oslcDialog');
  } else {
    var dialog = $('.dialog');
    // Do nothing if it's already showing.
    if (dialog.is(':hidden')) {
      $('<iframe/>', {
        src: 'newBug.html'
      }).css({
        border: 0,
        width: '450px',
        height: '395px'
      }).appendTo('#dialogContainer');
      dialog.fadeIn('fast');
    }
  }
}

O resultado da chamada da função na Listagem 5 é a caixa de diálogo de criação de defeito mostrada na Figura 2.

Figura 2. Caixa de diálogo de criação de defeito do aplicativo de amostra OSLC 3.0
Screenshot of OSLC 3.0 sample application's creation dialog
Screenshot of OSLC 3.0 sample application's creation dialog

Neste momento, o preenchimento do formulário deve ser uma atividade fácil para qualquer pessoa que já tenha usado a web. No entanto, ao enviar, ocorre uma nova manipulação semântica. Observe atentamente a Listagem 6.

Lista 6. Enviando informações de erro como JSON-LD
<script type="text/javascript">
    // Our JSON-LD context for creating defects
    var context = {
        oslc_cm: "http://open-services.net/ns/cm#",
        dcterms: "http://purl.org/dc/terms/",
        Defect: "oslc_cm:Defect",
        description: "dcterms:description",
        severity: {
            "@id": "oslc_cm:severity",
            "@type": "@id"
        },
        title: "dcterms:title"
    };

...

    function submit() {
        // Post the form as JSON-LD to the bug container.
        var bug = {
            "@id": "",
            "@type": "Defect",
            "@context": context,
            title: $("#title").val(),
            description: $("#description").val(),
            severity: $("#severity").val()
        };

        var request = $.ajax({
                url: 'r/bugs',
                data: JSON.stringify(bug),
                type: 'post',
                contentType: 'application/ld+json',
                success: function(data, status, xhr) {
                    var location = xhr.getResponseHeader('Location');
                    var response = {
                        "oslc:results": [ {
                                "oslc:label": bug.title,
                                "rdf:resource": location
                        } ]
                    };
                    sendMessage(response);
                }
        });
    }

Os dados do formulário são coletados e capturados com a mágica do JQuery para gerar o JSON simples. Não há nada de errado com o JSON simples quando ambas as partes concordam sobre o que os termos e as estruturas significam, mas como um padrão de interação, o JSON não se dimensiona a uma grande variedade de parceiros.

Falando de padrões mais ricos, podemos facilmente compartilhar informações com qualquer pessoa que as entenda. Embora o JSON seja um padrão, ele não especifica nenhum meio de interpretar a estrutura de dados ou os termos de palavra-chave usados. Lembre-se do primeiro artigo nesta série, que um dos motivos pelos quais a RDF funciona é que ele usa uma estrutura gráfica de dados e (frequentemente) identificadores globais. O uso desses padrões não envolve a necessidade de explicar a estrutura antecipadamente para os destinatários. Com a mesma finalidade, podemos contextualizar o JSON como JSON-LD, que suporta a serialização de estruturas de gráfico direcionado, como RDF. O JSON real não precisa mudar. Somente é necessário fornecer um contexto para interpretar os dados, que é o que ocorre na Listagem 6. O contexto especificado é usado para mapear os termos simples a partir do formulário para os termos do vocabulário do OSLC. Esse JSON de formação especial é transformado em RDF pelo contêiner como se fosse realizado POST como Turtle em primeiro lugar. O fato de que ele interopera com ferramentas como JQuery é simplesmente um avanço fascinante.

Neste momento, é possível inserir alguns erros ou usar o atalho e selecionar o link Criar alguns? na Figura 1. Esse atalho gera alguns erros de estoque a partir de dados falsos, conforme é mostrado em Figura 3. Um sistema de rastreamento de defeitos real teria um banco de dados mais permanente ou um armazenamento auxiliar por trás, mas o aplicativo de amostra controla os defeitos enviados suficientemente bem para propósito de aprendizado.

Figura 3. Aplicativo de amostra OSLC 3.0 com alguns dados
OSLC 3.0 sample application with data
OSLC 3.0 sample application with data

Cada um dos defeitos em Figura 3 tem um link clicável em um navegador. Neste momento, se eu clicar ou passar o mouse sobre o link, será exibida uma renderização de HTML dos defeitos, como é mostrado em Figura 4. Esse é outro recurso da especificação OSLC 3.0 Delegated Dialogs.

Figura 4. Aplicativo de amostra OSLC 3.0 com visualização prévia de dados
OSLC 3.0 Sample Application with Data Preview
OSLC 3.0 Sample Application with Data Preview

No entanto, esse não é um simples aplicativo da web. O contêiner também informa sobre a presença desses erros pelos meios de interação estabelecidos (ou seja, solicitações de HTTP). Na Listagem 7, é possível ver a presença desses erros.

Lista 7. Descobrindo recursos de defeito na LDP
> http get http://localhost:8080/oslc3/r/bugs
 
HTTP/1.1 200 OK
Accept-Post: text/turtle,application/json,application/json
Allow: GET,HEAD,POST,OPTIONS
Cache-Control: no-cache
Content-Type: text/turtle
Date: Mon, 17 Aug 2015 01:42:21 GMT
ETag: "a9c13497ed1dd32b4ec2368094c2cc30"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Link: <http://open-services.net/ns/cm#Defect>;
  rel="http://open-services.net/ns/core#creationType"
Link: <http://localhost:8080/oslc3/Defect-shape.ttl>;
  rel="http://www.w3.org/ns/ldp#constrainedBy"
Link: <http://localhost:8080/oslc3/r/bugs/creationDialog>;
  rel="http://open-services.net/ns/core#creationDialog"
Server: Jetty(9.2.2.v20140723)
Transfer-Encoding: chunked
Vary: Accept,Prefer

@base <http://localhost:8080/oslc3/r/bugs> .
<> a <http://www.w3.org/ns/ldp#BasicContainer> ;
  <http://purl.org/dc/terms/title> "Bug Container" ;
  <http://www.w3.org/ns/ldp#contains>
    <bugs/4> , <bugs/3> , <bugs/2> , <bugs/1> .

Se eu solicitar um dos defeitos pelos seus identificadores de recurso, como na Listagem 8, esses detalhes poderão ser visualizados. Os clientes do sistema têm a oportunidade de decidir como interagir os conteúdos do contêiner. Eles podem usar uma UI fornecida, usar uma interface customizada baseada nos metadados ou usar os conteúdos diretamente como dados orientados a recursos.

Lista 8. Buscando um recurso individual
> http get http://localhost:8080/oslc3/r/bugs/2
 

HTTP/1.1 200 OK
Allow: GET,HEAD,OPTIONS,DELETE
Cache-Control: no-cache
Content-Type: text/turtle
Date: Mon, 17 Aug 2015 02:27:44 GMT
ETag: "10337b40b28dae5800f02ee476a315f7"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://localhost:8080/oslc3/r/bugs/2/compact>; rel="http://open-services.net/ns/core#Compact"
Server: Jetty(9.2.2.v20140723)
Transfer-Encoding: chunked
Vary: Accept,Prefer

@base <http://localhost:8080/oslc3/r/bugs/2> .
@prefix <http://www.w3.org/2001/XMLSchema#>
<> a <http://open-services.net/ns/cm#Defect> ;
  <http://open-services.net/ns/cm#severity>
    <http://open-services.net/ns/cm#Normal> ;
  <http://purl.org/dc/terms/created>
    "2015-08-15T06:02:28.772Z"^^xsd:dateTime ;
  <http://purl.org/dc/terms/description>
    "I thought we wanted the UI to look really blue? What happened?" ;
  <http://purl.org/dc/terms/identifier> "2" ;
  <http://purl.org/dc/terms/title> "Product Z isn't blue enough." .

O contêiner tem links que podem ser descobertos para seus conteúdos. Cada um desses recursos também pode ser tratado individualmente. Geralmente, não é interessante iterar sobre cada um dos resultados para localizar o que eu procuro. Portanto, convém que o aplicativo de amostra suporte SPARQL — não uma implementação SPARQL totalmente completa, mas isso será abordado na próxima seção. Por enquanto, se eu selecionar o link do terminal SPARQL no aplicativo de amostra, será exibida a página mostrada em Figura 5. A página contém uma caixa de entrada de consulta, um botão para enviar a consulta e um espaço para exibir os resultados.

Figura 5. Terminal SPARQL do aplicativo de amostra OSLC 3.0
OSLC 3.0 sample application SPARQL endpoint
OSLC 3.0 sample application SPARQL endpoint

A recuperação da lista de todos os defeitos com uma UI SPARQL não é mais tangível do que buscar os resultados usando diretamente o contêiner LDP. Eu gostaria de poder fazer perguntas específicas. No Figura 6 eu mostro os resultados de perguntar informações sobre defeitos de uma gravidade específica.

Figura 6. Resultados do SPARQL do aplicativo de amostra OSLC 3.0
OSLC 3.0 sample application SPARQL results
OSLC 3.0 sample application SPARQL results

Neste estágio, eu já mostrei um sistema de rastreamento de defeitos funcional (embora minimalista), expresso em termos de padrões orientados à web. O sistema usa identificadores baseados em padrões, um modelo de dados padrão, mecanismos de consulta padrão e até mesmo elementos da UI padrão para coletar e exibir conteúdo específico do domínio. Essas são todas etapas importantes rumo ao desenvolvimento de sistemas fracamente acoplados, orientados a recursos.

Qualquer ferramenta que entenda esses padrões e os termos do vocabulário do OSLC agora pode interagir com esse contêiner.

Você tem acesso à implementação no código recuperado do GitHub, mas nada disso foi salientado nesta discussão. Qualquer ferramenta que entenda esses padrões e os termos do vocabulário do OSLC agora pode interagir com esse contêiner. Um pequeno conhecimento especializado é necessário para produzir um conteúdo que possa ser consumido, ou para consumir o conteúdo produzido. Uma ferramenta poderia suportar nativamente esses padrões ou poderia ter um adaptador de algum tipo para agrupar suas APIs e seus mecanismos de armazenamento existentes para produzir um conteúdo adequado.

Esse processo poderia ser repetido para várias outras verticais do Comitê Técnico do OSLC, e a situação envolveria um bom histórico de integração. As ferramentas seriam previsíveis e interoperáveis. Os sistemas de rastreamento de problemas arbitrários não apenas podem ser conectados a sistemas de relatório de resultados de teste, sistemas de requisitos e outros sistemas arbitrários, como também é possível intercalar informações arbitrárias adicionais nos vocabulários do OSLC padrão. Os termos do FOAF, Dublin Core, VoID, ou mesmo vocabulários customizados podem ser facilmente inter-relacionados, como esta série mostrou.

Qualquer informação adicional de outros vocabulários pode tornar-se parte das consultas SPARQL para a localização de informações relevantes. Usando termos FOAF, seria possível capturar as informações de identidade e conteúdo para desenvolvedores individuais designados à correção de defeitos. Não são necessários novos armazenamentos ou esquemas de dados para aceitar esses novos detalhes, o que seria claramente útil nesse tipo de sistema. Surgem novas capacidades, como "Descobrir quem é responsável por esse erro" ou "Reunir os endereços de e-mail de todos os desenvolvedores que estejam trabalhando em tarefas designadas a este sprint para lembrá-los sobre o congelamento de código na quinta-feira".

No entanto, a manipulação de dados vinculados é apenas o início,— não um ponto final. Como demonstro na seção final, é fácil colocar ainda mais recursos em camadas sobre o sistema existente, usando as técnicas já apresentadas.

Ampliando o aplicativo de amostra

A adoção desse tipo de pensamento orientado a recurso e baseado em padrões abre novas oportunidades. Os conceitos importantes têm identificadores estáveis e são livres para assumir várias formas durante a negociação de conteúdo. Os sistemas que podem surgir como novas representações passam a estar em voga.

Os termos usados em um determinado vocabulário também podem ser convertidos em outros termos de outras origens ou que sejam significativos para outros clientes. Os elementos do gráfico podem definir conceitos novos e ainda indefinidos. O aplicativo de amostra não fornece uma implementação SPARQL totalmente completa. Ele não suporta o protocolo SPARQL ou a capacidade de emitir consultas CONSTRUCT com relação a ele. Por agora, ele somente suporta consultas SELECT.

Não é um salto muito grande imaginar esse suporte sendo incluído, mas por enquanto isso não é necessário. Temos a capacidade de extrair os dados e exportá-los para outra ferramenta faça isso (por exemplo, Stardog, Virtuosoou Apache TDB). Com um mecanismo SPARQL mais completo, seria possível criar e ampliar o modelo de dados, executando consultas e incluindo os resultados novamente no nosso entendimento do mundo.

Por exemplo, o que constitui o defeito com a prioridade mais alta pode ser alterado ao longo da duração de um projeto. Quando uma equipe está conduzindo uma liberação de produto viável mínimo (MVP), qualquer coisa que impeça o progresso pode ser o mais urgente para se trabalhar. Mais tarde, os defeitos relacionados a um sistema específico, um trabalho específico financiado pelo cliente ou qualquer outra visão potencial da lista não processada de defeitos poderá mudar o foco do trabalho dos desenvolvedores. Ferramentas e práticas ágeis ajudam a gerenciar a mudança de prioridades, mas poder redefinir os dados em tempo real também seria uma boa capacidade. Os sistemas racionais eficientes poderiam facilitar essa capacidade, mas uma consulta de construção SPARQL simples, como o exemplo na Listagem 9 também poderia.

Lista 9. Reformulando os dados usando SPARQL
PREFIX oslc_cm: <http://open-services.net/ns/cm#>
PREFIX ex: <http://example.com/ns/>

CONSTRUCT {
   ?s a ex:HighestPriority
} WHERE {
   ?s a oslc_cm:Defect ;
     oslc_cm:severity oslc_cm:Blocker .
}

A consulta CONSTRUCT cria uma nova instrução para identificar quais defeitos devem ser considerados como a prioridade mais alta, com base em um padrão gráfico. Nesse caso, qualquer defeito com o status Blocker é qualificado. Os resultados poderiam ser diferentes para cada desenvolvedor. Novas regras podem alterar a definição de prioridade apenas ao usar uma consulta diferente, sem qualquer tipo de código customizado. Como o modelo não separa os dados dos metadados, qualquer parte do gráfico pode ser usada para definir as regras. Como qualquer aspecto dos dados de qualquer domínio pode ser incorporado, a eficiência e a flexibilidade potenciais devem ser óbvias.

Mesmo sem um armazenamento triplo elaborado ou o suporte total do SPARQL, é possível extrair os dados a partir dos dados falsos do aplicativo de amostra e usar a ferramenta de linha de comando SPARQL padrão a partir da API Jena, para executar a consulta com relação aos dados existentes:

> sparql --data 1.ttl --data 2.ttl --data 3.ttl --data 4.ttl --query sparql/construct.rq 
 
@prefix ex:    <http://example.com/ns/> .
@prefix oslc_cm: <http://open-services.net/ns/cm#> .

<http://localhost:8080/oslc3/r/bugs/3>
  a ex:HighestPriority .

Aqui, é possível notar que essa ferramenta reutilizável,— que não sabe nada sobre os domínios em discussão— é capaz de identificar o número de erro 3 como o erro HighestPriority, com base na definição em mãos. Se o suporte do SPARQL para o aplicativo de amostra for ampliado, qualquer ferramenta externa poderá localizar o conteúdo, com base em um contexto externo arbitrário codificado em uma consulta. A inclusão de suporte para o protocolo SPARQL e os formulários CONSTRUCT permitiria que qualquer ferramenta ou cliente executasse algo como o seguinte:

PREFIX ex: <http://example.com/ns/>

SELECT ?defect
 
FROM <http://localhost:8080/oslc3/sparql?query=PREFIX%20oslc_cm%3A%20%3Chttp%3A%2F \
%2Fopen-services.net%2Fns%2Fcm%23%3E%0APREFIX%20ex%3A%20%3Chttp%3A%2F%2F \
example.com%2Fns%2F%3E%0A%0ACONSTRUCT%20%7B%0A%20%20%20%3Fs%20a%20ex%3A \
HighestPriority%0A%7D%20WHERE%20%7B%0A%20%20%20%3Fs%20a%20oslc_cm%3A \
Defect%20%3B%0A%20%20%20%20%20oslc_cm%3Aseverity%20oslc_cm%3ABlocker \
%20.%0A%7D%0A>
 
WHERE {
 
   ?defect a ex:HighestPriority .
 
}

Nesse cenário, a ferramenta está reformulando o conteúdo de dados de amostra dinamicamente e recuperando os resultados usando a consulta CONSTRUCT anterior. Ela foi codificada pela URL e passada para o suporte do protocolo SPARQL (atualmente inexistente).

Como outro exemplo de desenvolvimento com base em dados vinculados orientados a recurso, é fácil imaginar um cenário no qual uma ferramenta de colaboração on-line seja ampliada para entrelaçar conversas sobre o processo de desenvolvimento de software, a fim de discutir diversas questões. Usando tecnologias como RDFa ou HTML5 Microdata, um aplicativo da web que captura conversas poderia codificar uma representação RDF da conversa. A estrutura do documento HTML mostrando a conversa conteria metadados que qualquer ferramenta padrão RDFa ou HTML5 com reconhecimento de microdados poderia extrair no Turtle, como na Listagem 10.

Lista 10. Extraindo conversas sobre defeitos
PREFIX oslc: <http://open-services.net/ns/core#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX : <http://example.com/discussion#>

:discussion1 a oslc:Discussion ;
   oslc:discussionAbout <http://localhost:8080/oslc3/r/bugs/4> ;
   oslc:comment :comment1, :comment2, :comment3, :comment4 .
 
:comment1 a oslc:Comment ;
  dcterms:created "2015-08-01T10:59:25.291Z" ;
  dcterms:creator <http://example.com/people/bob> ;
  dcterms:description "I think that was Eric's doing." ;
  dcterms:title "Uhm..." .

:comment2 a oslc:Comment ;
  dcterms:created "2015-08-01T11:02:19.090Z" ;
  dcterms:creator <http://example.com/people/eric> ;
  dcterms:description "Are you kidding? No way!" ;
  dcterms:title "Re: Uhm..." ;
  oslc:inReplyTo :comment1 .

:comment3 a oslc:Comment ;
  dcterms:created "2015-08-01T11:15:44.333Z" ;
  dcterms:creator <http://example.com/people/bob> ;
  dcterms:description "Here's the GitHub commit: <...>" ;
  dcterms:title "Evidence" ;
  oslc:inReplyTo :comment2 .

:comment4 a oslc:Comment ;
  dcterms:created "2015-08-01T12:20:54.102Z" ;
  dcterms:creator <http://example.com/people/eric> ;
  dcterms:description "Oops. My bad.";
  dcterms:title "Re: Evidence" ;
  oslc:inReplyTo :comment3 .

Esse mecanismo poderia não apenas ser usado para classificar, priorizar e designar trabalho, mas a ausência desse tipo de discussão também se torna um ponto de dados significativo. Uma consulta SPARQL poderia facilmente perguntar para localizar todos os defeitos para os quais não haja nenhuma discussão a respeito. É tão fácil localizar partes do gráfico que não correspondem a determinado padrão quanto é localizar as partes que correspondem. Isso pode ser uma atividade crucial em um projeto para validar se foram feitas estimativas adequadas. Se ninguém tiver falado sobre o assunto, os números relacionados ao projeto poderão ser duvidosos.

O ponto principal é que o código que gerencia a conversa tem apenas uma ligação mínima com o software de rastreamento de problemas por meio de dados, mas essa integração acumula novos recursos de valor agregado. Espero que agora seja mais fácil imaginar as integrações que agregam valor e requerem um esforço surpreendentemente mínimo entre todas as ferramentas potenciais envolvidas no desenvolvimento de software.

Conclusão

O desenvolvimento com base em um conjunto de padrões criados para compartilhar informações é claramente uma estratégia vencedora para uma coleção diversificada de domínios, como o gerenciamento de artefatos de várias disciplinas da engenharia entre um grande número de ferramentas, parceiros e partes interessadas.

Não sei o que o futuro reserva para o OSLC sobre a orientação desses novos organizadores. Obviamente, as especificações OSLC 3.0 precisam ser concluídas, e mais ferramentas precisam ser modificadas para suportar as novas abordagens. Têm ocorrido várias discussões sobre que tipo de compatibilidade pode ou deve ser mantido entre as especificações 2.0 e 3.0. Os aplicativos clientes que foram desenvolvidos em torno de APIs de nível de linguagem podem ser privados de mudanças, e os aplicativos que funcionam no nível do REST e da RDF não devem ser tão difíceis de migrar.

Esses são os novos e emergentes padrões, assim como o são muitas das tecnologias nas quais eles são desenvolvidos. Nem todo mundo entende ou aprecia o que eles oferecem. Felizmente, iniciativas como o Linked Data Project destacam a escala e a eficiência com as quais os grupos podem compartilhar e integrar informações entre domínios arbitrários.

O que eu espero ter demonstrado nesta série é que o desenvolvimento com base em um conjunto de padrões, criado para compartilhar informações, é claramente uma estratégia vencedora para uma coleção diversificada de domínios — como o gerenciamento de artefatos de várias disciplinas da engenharia entre um grande número de ferramentas, parceiros e partes interessadas. A tentativa de fazer isso com esquemas de banco de dados rígidos ou documentos de valor da chave ad hoc seria extremamente mais complicada e teria menor probabilidade de sucesso.

O projeto OSLC inaugura um novo cenário de adoção desses padrões para os propósitos para os quais eles foram criados. Espero que você veja que eles têm uma probabilidade de serem igualmente úteis a qualquer outro tipo de esforço de integração que possa surgir.


Recursos para download


Temas relacionados

  • Eclipse Lyo: experimente com recursos OSLC por meio de uma implementação de referência de software livre.
  • Webinar do JSON-LD: assista o webinar do Brian Sletten sobre JSON-LD.
  • Implementação do OSLC na nuvem: brinque com o aplicativo de amostra em execução no Bluemix.
  • Recursos OSLC: leia sobre as tecnologias, os membros, os tutoriais e os projetos do Open Services for Lifecycle Collaboration (OSLC).
  • Linked Data Platform: leia sobre uma especificação W3C para definir uma plataforma para leitura e gravação de coletas de dados vinculados.

Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre, Tecnologia Java
ArticleID=1018226
ArticleTitle=Integração de dados em escala: Explore exemplos de OSLC
publish-date=10232015