Rumo a um Perfil Básico do Linked Data

Uma coleção das melhores práticas e uma abordagem simples da arquitetura Linked Data

W3C define uma ampla variedade de padrões de Semantic Web e Linked Data adequados para muitos casos de uso possíveis. Ao usar o Linked Data como uma tecnologia de integração de aplicativo no domínio Application Lifecycle Management (ALM), a IBM descobriu que há frequentemente vários caminhos possíveis para aplicar os padrões existentes, desde que seja fornecida alguma orientação sobre como combiná-los. Este artigo explica como determinar as informações do histórico e uma proposta para um Perfil Básico do Linked Data.

Steve Speicher, IBM Senior Technical Staff Member, OSLC Lead Architect, IBM

Photo of Steve SpeicherSteve Speicher é engenheiro de software senior da IBM e se concentra em soluções e integrações de gerenciamento de mudanças do Rational. Ele é o gerente de área do tópico Open Services for Lifecycle Collaboration (OSLC) Change Management, que fornece especificações abertas baseadas em REST, assim como implementações nos produtos de gerenciamento de mudanças Rational. Anteriormente, Steve trabalhou em iniciativas emergentes de padronização nas áreas de saúde e documentos compostos (W3C).


nível de autor Contribuidor do
        developerWorks

Martin Nally, Chief Technical Officer, IBM Rational Software, IBM

Martin Nally, IBM Fellow, é vice-presidente e diretor de tecnologia da divisão do software Rational da IBM. Martin passou a fazer parte da IBM em 1990 e trouxe 10 anos de experiência no segmento de mercado. Ele ocupou vários cargos de arquitetura e desenvolvimento na IBM, inclusive arquiteto e desenvolvedor principal do IBM VisualAge/Smalltalk e VisualAge/Java. Martin pertencia a uma equipe de três que lançou o projeto IBM que posteriormente tornou-se a estrutura do Eclipse. Em seguida, liderou a arquitetura, design e desenvolvimento do WebSphere Studio, que evoluiu para o Rational Application Developer. Mais recentemente, foi um dos líderes da movimentação do portfólio do Rational para uma arquitetura baseada na web e colaborou na criação do Open Services for Lifecycle Collaboration, uma arquitetura de integração, e para a tecnologia Jazz, um conjunto de serviços comuns usados para combinar ferramentas IBM e não IBM e criar um sistema integrado.



22/Dez/2011

Motivação

Existe o interesse de usar tecnologias Linked Data para mais de um propósito. O interesse em tais tecnologias existe para expor informações - registros públicos, por exemplo - na Internet, em um formato legível por máquina. Existe também interesse em usá-las para inferir novas informações nas já existentes, por exemplo, em aplicativos farmacêuticos ou no IBM Watson ™ (consulte a seção Recursos para obter links para mais informações). A equipe do IBM® Rational® tem usado o Linked Data como um modelo de arquitetura e tecnologia de implementação para integração de aplicativo.

O software do Rational é um fornecedor de ferramentas de desenvolvimento de software, especialmente as que suportam o processo de desenvolvimento de software geral, por exemplo, ferramentas de rastreamento de erros, gerenciamento de requisitos e gerenciamento de teste. Como muitos fornecedores que vendem diversos aplicativos, é possível encontrar uma grande demanda de clientes que buscam um suporte melhor de processos de negócios mais completos (em nosso caso, processos de desenvolvimento de software) que ultrapassem os limites das funções, tarefas e dados tratados por diversas ferramentas. Essa demanda já existe há muitos anos e nosso segmento de mercado tentou várias abordagens de arquitetura diferentes para resolver esse problema. Estes são alguns exemplos:

  • Implementação de algum tipo de interface de programação de aplicativos (API) para cada aplicativo e, depois, a implementação do "glue code" em cada aplicativo, para explorar as APIs de outros aplicativos para vinculá-los conjuntamente.
  • Design de um banco de dados únicos para armazenar os dados de vários aplicativos, e implementação de cada um dos aplicativos nesse banco de dados. No setor de ferramentas de desenvolvimento de software, esses bancos de dados são frequentemente chamados de "repositórios".
  • Implementação de um "hub" ou "barramento" central que rege o processo de negócios mais amplo pela exploração das APIs descritas anteriormente.

Discutir as falhas de cada uma dessas abordagens está além do escopo deste artigo, mas é justo dizer que, embora cada uma delas tenha seus defensores e possa apontar para alguns casos bem-sucedidos, nenhuma é completamente satisfatória. Então, como uma alternativa, temos explorado o uso do Linked Data como uma tecnologia de integração de aplicativos nos últimos cinco anos. Vários produtos usando essa tecnologia foram enviados e, no geral, estamos satisfeitos com o resultado. Temos mais produtos em desenvolvimento que usam tais tecnologias, e percebemos um forte interesse nessa abordagem em outras partes da nossa empresa.

Embora estejamos satisfeitos - até mesmo entusiasmados - com os resultados obtidos usando o Linked Data como uma tecnologia de integração, a adoção bem-sucedida é considerada uma etapa difícil. Foram necessários muitos anos de experimentação para obter o nível de compreensão que se tem hoje. Alguns erros custosos foram cometidos no decorrer do caminho e nenhum fim imediato foi reconhecido para os desafios e aprendizados diante de nós.

Até onde é possível dizer, não existem muitas pessoas tentando usar as tecnologias do Linked Data do modo como as estamos utilizando, e as poucas informações disponíveis sobre as melhores práticas e armadilhas estão amplamente dispersas. Acredita-se que o Linked Data tem o potencial de resolver alguns problemas importantes que têm frustrado o segmento de mercado de TI por muitos anos ou, pelo menos, de avançar significativamente nessa direção. Mas esse potencial só será concretizado quando for possível estabelecer uma base de conhecimento mais completa sobre como explorar essas tecnologias. Em alguns casos, também existem lacunas nos padrões do Linked Data que precisam ser resolvidas.

Para ajudar nesse processo, estamos dispostos a compartilhar informações sobre como usamos essas tecnologias, as melhores práticas e antipadrões que identificamos, e as lacunas de especificações que tivemos que preencher. Essas melhores práticas e antipadrões podem ser classificados de acordo com as seguintes categorias (sem limitação):

Recursos
Um resumo das técnicas padrão e melhores práticas de HTTP e RDF que devem ser usadas, e os antipadrões que devem ser evitados, ao criar clientes e servidores que leiam e gravem Linked Data
 
Contêineres
Define os recursos que permitem a criação de novos, usando HTTP POST, e a localização de recursos existentes, usando HTTP GET
 
Paginação
Define um mecanismo de divisão das informações em grandes recursos em páginas que podem ser buscadas de modo incremental
 
Validação
Define um mecanismo simples para descrever as propriedades que determinado tipo de recurso deve ou pode ter
 

As seções a seguir fornecem detalhes sobre esta proposta para um Perfil Básico do Linked Data.


Trabalho relacionado

A intenção deste artigo é promover ideias e motivar esforços de especificação possivelmente em inúmeras comunidades. Esses esforços estão relacionados a esta proposta:

Workshop dos Padrões W3C Linked Enterprise Data
Esta proposta se destina a elaborar sobre o que é considerado ausente ou necessário, como abordado no documento de situação da IBM apresentado no workshop.

Open Services for Lifecycle Collaboration (OSLC)
A especificação OSLC Core v2 define alguns desses padrões e antipadrões, embora talvez não de um modo ideal. Essa proposta pode fornecer a base para um modo mais simples e mais alinhado aos padrões para aplicativos OSLC futuros.


Terminologia

Essas definições se baseiam na Arquitetura do W3C do World Wide Web e Hyper-text Transfer Protocol, HTTP/1.1 (consulte Recursos).

Link
Um relacionamento entre dois recursos quando um recurso (representação) se refere a outros recursos por meio de um URI. (referência: WWWArch)
 
Linked Data
Definido por Tim Berners-Lee com quatro regras:
  1. Usar URIs para nomear objetos.
  2. Usar URIs HTTP de modo que pessoas possam consultar esses nomes.
  3. Quando alguém consultar um URI, fornecer informações úteis, usando os padrões (RDF*, SPARQL).
  4. Incluir links em outros URIs de modo que eles possam descobrir mais coisas. (referência: LinkedData).
 
Especificação
O ato de descrever ou identificar alguma coisa precisamente ou de declarar um requisito preciso
 
Perfil Básico
Uma especificação que define os componentes de especificação necessários em outras especificações e fornece esclarecimentos e padrões
 
Cliente
Um programa que estabelece conexões para o propósito de enviar solicitações (referência: HTTP)
 
Cliente de Perfil Básico
Um cliente que adere às regras definidas no Perfil Básico
 
Servidor
Um programa aplicativo que aceita conexões para solicitações de serviço por retornar respostas

Observação: Qualquer programa dado pode ser um cliente e um servidor. Nosso uso desses termos se refere apenas à função que está sendo executada pelo programa de uma conexão específica, em vez de aos recursos do programa em geral. Da mesma forma, qualquer servidor pode atuar como um servidor, proxy, gateway ou túnel de origem, trocando o comportamento com base na natureza de cada solicitação (referência: HTTP).
 
Servidor de Perfil Básico
Um servidor que adere às regras definidas no Perfil Básico
 

Recursos do Perfil Básico

Os Recursos do Perfil Básico são recursos do HTTP Linked Data que se conforma a padrões e convenções simples. A maioria dos Recursos de Perfil Básico são recursos específicos do domínio que contêm dados para uma entidade em um domínio, e esse domínio pode ser comercial, governamental, científico, religioso ou de outro tipo. Alguns Recursos do Perfil Básico são definidos pelas especificações do Perfil Básico e são de domínio cruzado. Todos os Recursos do Perfil Básico seguem as regras do Linked Data anteriormente citada na seção Terminologia:

  1. Usar URIs para nomear objetos.
  2. Usar URIs HTTP de modo que pessoas possam consultar esses nomes.
  3. Quando alguém consultar um URI, fornecer informações úteis, usando os padrões (RDF*, SPARQL).
  4. Incluir links em outros URIs de modo que pessoas possam descobrir mais coisas.

O Perfil Básico inclui algumas regras. Algumas dessas regras podem ser consideradas como esclarecimento das regras básicas do Linked Data.

  1. Os Recursos de Perfil Básico são recursos HTTP que podem ser criados, modificados, excluídos e lidos usando métodos HTTP padrão.
    (Esclarecimento ou extensão da Regra 2 do Linked Data.) Os Recursos do Perfil Básico são criados pelo HTTP POST (ou PUT) para um recurso existente, excluído por HTTP DELETE, atualizado por HTTP PUT ou PATCH, e "buscado" usando HTTP GET. Adicionalmente, Recursos do Perfil Básicos podem ser criados, atualizados e excluídos usando SPARQL Update.
  2. Os Recursos do Perfil Básico usam RDF para definir seus estados.
    (Esclarecimento da Regra 3 do Linked Data.) O estado de um Recurso de Perfil Básico (no sentido de estado usado na arquitetura REST) é definido por um conjunto de trios RDF. Recursos binários e recursos de texto não são Recursos do Perfil Básico, visto que seus estados não podem ser fácil ou completamente representados no RDF. Os recursos XML podem ou não ser adequados como Recursos do Perfil Básico. Alguns recursos XML são realmente recursos orientados a dados codificados no XML que podem ser facilmente representados no RDF. Outros documentos XML são essencialmente marcados como documentos de texto que não são facilmente representados em RDF. Os Recursos do Perfil Básico podem ser combinados com outros recursos no mesmo aplicativo.
  3. É possível solicitar uma representação RDF/XML de qualquer Recurso do Perfil Básico.
    (Esclarecimento da Regra 3 do Linked Data.) Além disso, o recurso pode ter outras representações. Essas podem estar em outros formatos RDF (como Turtle, N3 ou NTriples), embora formatos não RDF (como HTML e JSON) também sejam adições populares, e conjuntos do Perfil Básico sem limites.
  4. Clientes do Perfil Básico usam Detecção de Colisão Otimista durante a atualização.
    (Esclarecimento da Regra 2 do Linked Data.) Como o processo de atualização envolve, primeiro, obter um recurso, em seguida, modificá-lo e, posteriormente colocá-lo novamente no servidor, um conflito é possível (por exemplo, outro cliente pode ter atualizado o recurso desde a ação GET). Para mitigar esse problema, as implementações do Perfil Básico devem usar o cabeçalho HTTP If-Match e HTTP ETags para detectar colisões.
  5. Os Recursos do Perfil Básico usam tipos de mídia padrão.
    (Esclarecimento da Regra 3 do Linked Data.) O Perfil Básico não requer e não encoraja a definição de nenhum tipo de mídia novo. A meta do Perfil Básico é que qualquer cliente Linked Data ou RDF baseado em padrões possa ler e gravar dados do Perfil Básico; a definição de novos tipos de mídia pode impedir isso na maioria dos casos.
  6. Os Recursos do Perfil Básico usam vocabulários padrão.
    Os Recursos do Perfil Básico usam vocabulários comuns (classes, propriedades, e assim por diante) para conceitos comuns. Muitos websites definem seus próprios vocabulários para conceitos comuns, por exemplo, tipo de recurso, rótulo, descrição, criador, hora da última modificação, prioridade, enumeração dos valores de prioridade, e assim por diante. Isso é normalmente considerado uma característica boa pelos usuários que desejam que seus dados correspondam à terminologia e processos locais, mas é muito mais difícil para organizações integrar informações subsequentemente em uma visualização mais ampla. O Perfil Básico requer que todos os recursos exponham conceitos comuns usando um vocabulário comum para propriedades. Sites podem optar por expor adicionalmente os mesmos valores sob seus próprios nomes de propriedades privadas, nos mesmos recursos. No geral, o Perfil Básico evita, sempre que possível, a invenção de nomes de propriedade. Em vez disso, ele usa um dos padrões populares baseados em RDF, como os próprios padrões RDF, Dublin Core, e assim por diante. O Perfil Básico inventa URLs de propriedade quando nenhuma correspondência é encontrada nos vocabulários populares padrão. Observação: Diversas propriedades padrão recomendadas para uso nos Recursos do Perfil Básico são listadas abaixo.
  7. Os Recursos do Perfil Básico definem rdf:type explicitamente.
    A associação de um recurso em uma extensão de classe pode ser derivada implicitamente ou indicada explicitamente por um trio na representação do recurso que usa o predicado rdf:type e a URL da classe ou derivada implicitamente. No RDF, não há nenhum requisito para inserir o trio rdf:type em cada recurso, mas isso é uma prática recomendada, porque torna uma consulta mais útil nos casos em que inferência não é suportada. Lembre-se também de que um único recurso pode ter vários valores para rdf:type. Por exemplo, a entrada da dpbedia para Barack Obama tem dezenas de rdf:types. O Perfil Básico não configura nenhum limite para o número de tipos que um recurso pode ter.
  8. Os Recursos do Perfil Básico usam um número restrito de tipos de dados padrão.
    O RDF não define tipos de dados a serem usados para valores de propriedade, assim o Perfil Básico lista um conjunto de tipos de dados padrão a ser usado no Perfil Básico:
    • Boolean: Um tipo de operados booleano como especificado por XSD Boolean http://www.w3.org/2001/XMLSchema#boolean, referência: Tipos de Dados do XSD.
    • DateTime: Um tipo de data e hora como especificado por XSD dateTime http://www.w3.org/2001/XMLSchema#dateTime, referência: Tipos de Dados do XSD
    • Decimal: Um tipo de número decimal como especificado por XSD Decimal http://www.w3.org/2001/XMLSchema#decimal, referência: Tipos de Dados do XSD
    • Double: Um número de vírgula flutuante duplo como especificado por XSD Double http://www.w3.org/2001/XMLSchema#double, referência: Tipos de Dados do XSD.
    • Float: Um tipo de número de vírgula flutuante como especificada por XSD Float http://www.w3.org/2001/XMLSchema#float, referência: Tipos de Dados do XSD.
    • Integer: Um tipo de número inteiro como especificado por XSD Integer http://www.w3.org/2001/XMLSchema#integer, referência: Tipos de Dados do XSD.
    • String: Um tipo de cadeia de caractere como especificado por XSD String http://www.w3.org/2001/XMLSchema#string, referência: Tipos de Dados do XSD.
    • XMLLiteral: Um valor XML literal
      http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
  9. Clientes do Perfil Básico esperam encontrar propriedades e conteúdo desconhecidos.
    O Perfil Básico fornece mecanismos para que os clientes descubram listas de propriedades esperadas para recursos de propósito específico, além de presumir que qualquer recurso pode ter mais propriedade do que está listado. Alguns servidores suportarão apenas um conjunto fixo de propriedades para um tipo específico de recurso. Os clientes devem sempre presumir que o conjunto de propriedades de um recurso de determinado tipo em um servidor arbitrário pode ser aberto, no sentido que é possível que diferentes recursos do mesmo tipo não tenham as mesmas propriedades, e o conjunto de propriedades que é usado no estado de um recurso não é limitado a nenhum conjunto predefinido. No entanto, ao lidar com os Recursos do Perfil Básico, os clientes devem presumir que um servidor do Perfil Básico pode descartar trios de propriedades em face de um conhecimento anterior. Em outras palavras, os servidores podem restringir a si mesmo para um conjunto conhecido de propriedades, mas os clientes não podem. Ao fazer uma atualização usando HTTP PUT, um cliente de Perfil Básico deve preservar todos os valores de propriedades recuperados usando HTTP GET. Isso inclui todos os valores de propriedade que ele não altera ou compreende. (O uso de HTTP PATCH ou SPARQL Update em vez de HTTP PUT para atualizações evita esse fardo para os clientes.)
  10. Os clientes do Perfil Básico não presumem o tipo de um recurso no final de um link.
    Muitas especificações e aplicativos mais tradicionais têm um "modelo fechado", o que significa que qualquer referência de um recurso na especificação ou aplicativo necessariamente identifica um recurso na mesma especificação (ou uma especificação referenciada) ou aplicativo. Em contraste, a tag âncora HTML pode apontar para qualquer recurso endereçável por um URI HTTP, não apenas outros recursos HTML. O Perfil Básico trabalha como HTML nesse sentido. Uma referência ao URI HTTP em um Recurso do Perfil Básico pode, no geral, apontar para qualquer recurso, não apenas para um Recurso do Perfil Básico. Há numerosos motivos para manter um modelo aberto como o de HTML. Um deles é o que permite que dados que ainda não tenham sido definidos sejam incorporados na web no futuro. Outro motivo é o que permite que aplicativos individuais e sites evoluam com o decorrer do tempo. Se os clientes presumirem que sabem o que estará na outra extremidade do link, então os formatos de dados de todos os recursos através do fechamento transitivo de todos os links deverão ser mantidos estáveis para atualização de versão.

    Uma consequência dessa independência
    é que as implementações do cliente que atravessam links URI HTTP de um recurso para outro devem sempre ser codificados defensivamente e preparados para qualquer recurso no final do link. A codificação defensiva por implementadores do cliente é necessária para permitir que conjuntos de aplicativos que se comunicam pelo Perfil Básico sejam atualizados independentemente e estendidos de modo flexível.
  11. Servidores de Perfil Básico implementam validações simples para Criar e Atualizar.
    Servidores de Perfil Básico devem tentar facilitar para clientes programáticos para criar e atualizar recursos. Se implementações do Perfil Básico associam um lote de regras de validação muito complexas que precisam ser satisfeitas por uma atualização ou criação para serem aceitas, fica difícil ou impossível para um cliente usar o protocolo sem as informações adicionais extensivas específicas ao servidor que precisam ser comunicadas externamente das especificações do Perfil Básico. A abordagem recomendada é que os servidores permitam a criação e atualizações baseadas na classificação de validações simples que podem ser comunicadas programaticamente por uma forma (consulte a seção Restrições. As verificações adicionais que são necessárias para implementar políticas e restrições mais complexas devem resultar na sinalização do recurso como necessitando de mais atenção, mas não deve causar a falha da ação básica Criar ou Atualizar.

    É possível que alguns aplicativos ou sites tenham requisitos muitos estritos quanto às restrições complexas para dados e que eles não sejam capazes ou não desejem, mesmo temporariamente, permitir a criação dos recursos que não satisfazem todas essas restrições. Esses aplicativos ou sites precisam estar cientes de que, como consequência, podem dificultar ou impossibilitar para o software externo usar suas interfaces sem customização extensiva.
  12. Os Recursos do Perfil Básico sempre usam predicados RDF simples para representar links.
    Ao sempre representar links como valores de predicado simples, o Perfil Básico simplifica muito o conhecimento de como os links aparecerão nas representações e como consultá-los. Quando há uma necessidade de expressar propriedades em um link, o Perfil Básico inclui uma instrução RDF com o mesmo assunto, objeto e predicado que o link original, que é retido, mais quaisquer "propriedades adicionais do link". Os Recursos do Perfil Básico não usam "links inversos" para suportar navegação de um relacionamento na direção oposta, porque isso cria um problema de sincronização de dados e complica uma consulta. Em vez disso, o Perfil Básico presume que clientes podem usar consultas para procurar relacionamentos na direção oposta à direção suportada pelo link subjacente.

Propriedades comuns

As tabelas que seguem as propriedades da lista dos vocabulários bem conhecidos que são recomendados para uso nos Recursos do Perfil Básico. O Perfil Básico não requer nenhuma delas, mas uma especificação com base no Perfil Básico pode requerer uma ou mais dessas propriedades para determinado tipo de recurso.

Prefixos de namespace comumente usados
PrefixoURI do Namespace
dcterms http://purl.org/dc/terms/
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
bp http://open-services.net/ns/basicProfile#
xsd http://www.w3.org/2001/XMLSchema#

Do Dublin Core

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

PropriedadeFaixaComentário
dcterms:contributor dcterms:Agent O identificador de um recurso (ou nó em branco) que é um contribuidor das informações. Esse recurso pode ser uma pessoa ou grupo de pessoas ou, possivelmente, um sistema automatizado.
dcterms:creator dcterms:Agent O identificador de um recurso (ou nó em branco) que é o criador original do recurso. Esse recurso pode ser uma pessoa ou grupo de pessoas ou, possivelmente, um sistema automatizado.
dcterms:created xsd:dateTime O registro de data e hora da criação.
dcterms:description rdf:XMLLiteral Texto descritivo sobre o recurso representado como rich text no formato XHTML. Deve incluir somente conteúdo que seja válido e adequado dentro de um elemento <div> do XHTML.
dcterms:identifier rdfs:Literal Um identificador exclusivo para o recurso. Normalmente somente leitura e designado pelo provedor de serviços quando um recurso é criado. Normalmente não destinado para exibição do usuário final.
dcterms:modified xsd:dateTime A data em que o recurso foi alterado.
dcterms:relation rdfs:Resource O URI de um recurso relacionado. Esse é o predicado a ser usado quando você não sabe o que mais usar. Se você souber que tipo de relacionamento é esse, use um predicado mais específico.
dcterms:subject rdfs:Resource Deve ser um URI (consulte dbpedia.org). Do Dublin Core: "Normalmente o sujeito será representado usando palavras-chave, frases-chave ou códigos de classificação. A melhor prática recomendada é usar um vocabulário controlado. Para descrever o tópico espacial ou temporal do recurso, use o elemento Coverage."
dcterms:title rdf:XMLLiteral Um nome atribuído ao recurso. Representado como rich text no formato XHTML. Deve incluir apenas conteúdo que seja válido dentro de um elemento <span> do XHTML.

Do RDF

URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#

PropriedadeFaixaComentário
rdf:type rdfs:Class O tipo ou tipos do recurso. O Perfil Básico recomenda que os rdf:type(s) de um recurso sejam definidos explicitamente nas representações de recurso para facilitar a consulta com mecanismos de consulta de não inferência.

Do Esquema RDF

URI: http://www.w3.org/2000/01/rdf-schema#

PropriedadeFaixaComentário
rdfs:member rdf:Resource O URI (ou identificador de nó em branco) de um membro de um Contêiner.
rdfs:label rdf:Resource "Fornece uma versão legível por uma pessoa de um nome de recurso." (Do RDFS)

Contêiner do Perfil Básico

Muitos aplicativos HTTP e sites têm conceitos de organização que dividem o espaço geral dos recursos em Contêineres menores. As postagens do blog estão agrupadas em blogs, as páginas wiki estão agrupadas em wikis e os produtos estão agrupados em catálogos. Cada recurso criado no aplicativo ou site é criado dentro de uma instância nas entidades do tipo Contêiner, e os usuários podem listar os artefatos existentes dentro de uma instância. Não há nenhum contrato entre aplicativos ou sites, mesmo dentro de um domínio específico, em que tais conceitos de agrupamentos devam ser chamados, mas eles existem comumente e são importantes. Os contêineres respondem a duas questões básicas:

  1. Em quais URLs posso postar para criar novos recursos?
  2. Onde posso obter uma lista dos recursos existentes?

No mundo do XML, o Atom Publishing Protocol (APP) se popularizou como um padrão para responder a essas perguntas. O APP não é uma boa correspondência ao Linked Data, porque esse Perfil Básico mostra como os mesmos problemas que são resolvidos pelo APP para designs centrados em XML podem ser resolvidos por um padrão de uso simples do Linked Data com convenções simples de postagem para Contêineres RDF. Chamamos esses Contêineres RDF que admitem a postagem para os Contêineres de Perfil Básico. Estas são algumas de suas características:

  • Os clientes podem recuperar a lista de recursos existentes em um Contêiner do Perfil Básico.
  • Novos recursos são criados nos Contêineres do Perfil Básico ao fazer postagens para eles.
  • Qualquer recurso pode ser postado em um Contêiner do Perfil Básico. Um recurso não precisa ser um Recurso do Perfil Básico com uma representação de RDF para ser postado para um Contêiner de Perfil Básico.
  • Depois da postagem de um novo recurso para um Contêiner, o novo recurso aparecerá como um membro do Contêiner até que seja excluído. Um Contêiner também pode conter recursos que foram incluídos por outros meios, por exemplo, por meio da interface com o usuário do site que implementa o Contêiner.
  • O mesmo recurso pode aparecer em vários Contêineres. Isso acontecerá com frequência se um Contêiner for uma "visualização" para um Contêiner maior.
  • Os clientes podem obter informações parciais sobre um Contêiner de Perfil Básico sem recuperar uma representação completa de todo o seu conteúdo .

A representação de um Contêiner de Perfil Básico é um Contêiner RDF padrão que usa o predicado rdfs:member. Por exemplo, se você tiver um Contêiner com a URL http://example.org/BasicProfile/container1, ele poderá ter a representação ilustrada na Listagem 1.

Listagem 1. Representação de um Contêiner do Perfil Básico
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
<http://example.org/BasicProfile/container1>
        a rdfs:Container;
        rdfs:member <http://acme.com/members/000000000>;
        # … 999999998 more triples here …
        rdfs:member <http://acme.com/members/999999999>.

O Perfil Básico não reconhece ou recomenda o uso de outras formas de um Contêiner RDF, como Bag e Seq, porque eles não são amigáveis à consulta. Esta segue a orientação de uso do RDF padrão do Linked Data. .

O Perfil Básico recomenda o uso de um conjunto de propriedades padrão do Dublin Core com Contêineres. O assunto dos trios usando essas propriedades no próprio Contêiner.

rdfs:Propriedades do domínio do Contêiner
PropriedadeOcorrênciaFaixaComentário
dcterms:title zero ou um rdf:XMLLiteral Um nome atribuído ao recurso. Representado como rich text no formato XHTML. Deve incluir apenas conteúdo que seja válido dentro de um XHTML <span> .
dcterms:description zero ou um rdf:XMLLiteral Texto descritivo sobre o recurso representado como rich text no formato XHTML. Deve incluir apenas conteúdo que seja válido e adequado dentro de um XHTML <div> .
dcterms:publisher zero ou um dcterms:Agent Uma entidade responsável por tornar o Contêiner do Perfil Básico e seus membros disponíveis.
bp:containerPredicate exatamente um rdfs:Property O predicado dos trios cujos objetos definem os conteúdos do Contêiner.

Recuperando propriedades de não membros

A representação de um Contêiner que tenha muitos membros será grande. Quando examinamos nossos casos de uso, vimos que há vários casos importantes em que clientes necessitam acessar somente as propriedades de não membro do Contêiner. (As propriedades dcterms listadas nesta página podem não parecer importantes o suficiente para garantir a solução do problema, mas temos casos de uso que incluem outros predicados nos Contêineres, por exemplo, para fornecer informações de validação e associar SPARQL e pontos.) Como a recuperação da representação de todo Contêiner para obter essas informações é onerosa, estamos motivados a definir um modo para recuperar apenas os valores de propriedade de não membro. Fazemos isso definindo um recurso correspondente para cada Contêiner do Perfil Básico, denominado o "recurso não membro", que tem um estado que é um subconjunto do estado do Contêiner. O URI HTTP do recurso de não membro pode ser derivado do seguinte modo:

Se o URI HTTP do Contêiner for {url}, o URI HTTP do recurso não membro relacionado será {url}?non-member-properties. A representação de {url}?non-member-properties será idêntica à representação de {url}, exceto se os trios de associação estiverem ausentes. Os assuntos dos trios ainda são {url} (ou o que eles eram na representação do {url}), não {url}?non-member-properties. Qualquer servidor que não suporte recursos não membro deverá retornar um erro HTTP 404 Arquivo Não Encontrado quando um recurso não membro for solicitado.

Essa abordagem é análoga a usar HTTP HEAD em vez de HTTP GET. A diferença é que HTTP HEAD é usado para buscar os cabeçalhos de resposta para um recurso, em oposição à solicitação da representação inteira de um recurso usando HTTP GET. A Listagem 1 mostra um exemplo.

Listagem 2. Exemplo de HTTP GET, solicitação
GET /container1?non-member-properties HTTP/1.1
HOST: example.org
Accept: text/turtle
Listagem 3. Exemplo de HTTP GET, resposta
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix bp: <http://open-services.net/ns/basicProfile#>.
<http://example.org/container1>
        a rdfs:Container;
        dcterms:title "An Basic Profile Container of Acme Resources";
        bp:containerPredicate rdfs:member;
        dcterms:publisher <http://acme.com/>.

Designar motivação e histórico

Ao passo que o conceito de recursos de não membros não tem sido especialmente controverso, usar o padrão de URL {url}?non-member-properties para identificá-los o tem. Algumas pessoas acreditam que é uma intrusão inaceitável no espaço da URL que é possuído e controlado pelo servidor que define o {url}. Uma objeção mais prática é que os servidores respondem de modo imprevisível a URLs que não compreendem, especialmente aquelas que contêm um caractere ?. Por exemplo, alguns servidores retornarão o recurso identificado pela parte da URL que precede o ? e simplesmente ignora o restante.

Talvez seja possível mitigar esse problema usando um caractere diferente de ? no padrão da URL. Um design alternativo que foi abordado usa um campo de cabeçalho no cabeçalho de resposta da {url} para permitir que o servidor controle e comunique a URL do recurso não membro correspondente. A presença ou ausência do campo do cabeçalho permite que clientes saibam se o recurso não membro é suportado pelo servidor.

  • As vantagens dessa abordagem são que ela não afeta o espaço da URL do servidor e que funciona previsivelmente para servidores que não compreendem o conceito de um recurso não membro.
  • As desvantagens são que ela requer dois roundtrips de servidor, um HEAD e um GET, para recuperar os recursos não membro, e requer a definição de um cabeçalho HTTP, o qual, para pelo menos algumas pessoas, parece comparativamente pesado.

Considerações adicionais

Os Contêineres do Perfil Básico devem fornecer orientação nessas situações:

  • Quando dcterms:modified e/ou Etag muda, quando a associação do Contêiner muda para levar em consideração efetivamente o armazenamento em cache dos Contêineres
  • Quando há limitações de associação (normalmente, um recurso será parte apenas de um único Contêiner, embora possa haver exceções)

Validação e restrições do Perfil Básico

Os recursos do Perfil Básico são recursos do RDF e o RDF tem a característica oportuna de "poder dizer tudo sobre todos". Isso significa que, em princípio, qualquer recurso pode ter qualquer propriedade e não há nenhum requisito que dois recursos qualquer tenham o mesmo conjunto de propriedades, mesmo se eles tiverem o mesmo tipo ou tipos. Na prática, no entanto, as propriedades que estão definidas nos recursos normalmente seguem padrões regulares que são ditados pelos usos dos recursos. Embora um recurso específico possa ter propriedades arbitrárias, quando visualizadas da perspectiva de determinado aplicativo ou caso de uso, o conjunto de propriedades e os valores das propriedades que são apropriadas para esse recurso nesse aplicativo frequentemente serão previsíveis e restritos. Por exemplo, se um servidor tiver recursos que representam produtos de software e erros, para os propósitos de exibição de informações em formatos tabulares, de criação e atualização de recurso, ou outros propósitos, talvez um cliente queira saber que propriedades os produtos de software e erros têm nesse servidor. A Validação do Perfil Básico e a especificação das Restrições visam capturar informações sobre tais propriedades e restrições.

A distinção entre o recurso e os casos de uso de que ele participa é importante para nós. Tecnologias tradicionais como bancos de dados relacionais restringem o conjunto total de propriedades que uma entidade pode ter. No Perfil Básico, visamos apenas definir as propriedades que um recurso pode ter quando visualizado pelas lentes de um aplicativo ou uso de caso específico, enquanto retém a capacidade dos mesmos recursos para ter um conjunto arbitrário de propriedades para suportar outros aplicativos e casos de uso.

O conjunto de propriedades que um recurso pode ter ou terá não está necessariamente vinculado ao seu tipo, mas a exploração do padrão em que recursos do mesmo tipo têm as mesmas propriedades é uma abordagem muito tradicional que suporta o desenvolvimento de muitos aplicativos úteis. Algumas vezes, o conhecimento dos tipos e propriedades do aplicativo está codificado permanentemente no software, mas há muitos casos em que é desejável representar esse conhecimento nos dados. O Perfil Básico fornece tipos de recursos denominados Shape e PropertyConstraint para representar esses dados.

Observe o Shape com outros padrões:
Embora estejamos muito familiarizados com bancos de dados relacionais e programação orientada a objetos com o modelo em que as propriedades válidas são restritas pelo tipo, esse não é o modelo "originário" do RDF, nem é o comum. O modelo familiar indica que, se você for de tipo X, terá essas propriedades, que irão possuir certos tipos de valores. Em geral, o RDF e os modelos comuns funcionam de outra maneira: se você possuir essas propriedades, deve ser do tipo X. Não existem construções OWL ou RDFS que nos permitem afirmar que, "da perspectiva do aplicativo, X, os recursos Y de tipo RDF terão a lista de propriedades Z", nem sobre a restrição dos tipos de valores dessas propriedades.

Classe: PropertyConstraint

URI: http://open-services.net/ns/basicProfile#PropertyConstraint

Propriedades do domínio bp:PropertyConstraint

PropriedadeOcorrênciaFaixaComentário
rdfs:label zero ou um rdfs:Literal Um nome legível por humanos para o assunto. (do rdfs)
rdfs:comment zero ou um rdfs:Literal Uma descrição do recurso do assunto. (do rdfs)
bp:constrainedProperty exatamente um rdfs:Property O URI do predicado sendo restrito.
bp:rangeShape zero ou um bp:Shape Um bp:Shape que descreve o rdfs:Class que a faixa do intervalo.
bp:allowedValue zero ou muitos faixa do assunto Um valor permitido para a propriedade. Se houver elementos bp:allowedValue e um recurso bp:AllowedValue, então o conjunto completo de valores admissíveis é a união de ambos.
bp:AllowedValues zero ou muitos bp:AllowedValues Um recurso com os valores admissíveis para a propriedade que está sendo definida.
bp:defaultValue zero ou um faixa do objeto Um valor padrão para a propriedade
bp:occurs exatamente um rdfs:Resource Deve ser um destes três:
http://open-service.net/ns/basicProfile#Exactly-one
ouhttp://open-service.net/ns/ basicProfile#Zero-or-one, http://open-service.net/ns/basicProfile#Zero-or-many
ou http://open-service.net/ns/ basicProfile#One-or-many
bp:readOnly zero ou um variáveis booleanastrue se a propriedade for somente leitura. Se estiver configurada ou não como false, a propriedade é gravável. Os provedores devem declarar uma propriedade somente leitura quando mudanças no valor dessa propriedade não forem aceitas em PUT. Os consumidores devem observar que a conversa não se aplica: provedores podem rejeitar uma alteração para o valor de uma propriedade gravável.
bp:maxSize zero ou um Número inteiro Para propriedade String apenas, especifica o máximo de caracteres permitidos. Se não estiver configurado, não há nenhum máximo ou o máximo está especificado em outra parte.
bp:valueType zero ou um rdfs:Resource Para literais, consulte XSD Datatypes.

É contestável se devemos ter uma classe bp:PropertyConstraint separada com uma propriedade denominada bp:constrainedProperty ou se seria melhor usar rdfs:Property e simplesmente definir novos predicados com rdfs:Property como o domínio.

Importante:

No entanto, é importante não usar rdfs:range, porque as semânticas são diferentes.

Classe: bp:AllowedValues

URI: http://open-services.net/ns/basicProfile#AllowedValues

Propriedades do domínio bp:AllowedValues

PropriedadeOcorrênciaFaixaComentário
bp:allowedValue zero ou muitos a mesma faixa da propriedade proprietária Valor permitido

Classe: bp:Shape

URI: http://open-services.net/ns/basicProfile#Shape

Propriedades do domínio bp:Shape

PropriedadeOcorrênciaFaixaComentário
dcterms:title zero ou um rdfs:XMLLiteral Título
bp:describedClass exatamente um rdfs:Class Classe descrita
bp:propertyConstraints zero ou um rdfs:List A lista de propertyConstraints das propriedades dessa Shape. Os domínios do PropertyConstraints devem ser compatíveis com a describedClass.

Semânticas de validação

As semânticas de validação são expressas pelo mapeamento das definições de propriedade e classe nos termos da semântica SPARQL ASK. Isso permite um modo declarativo no RDF para definir as restrições ao usar a especificação SPARQL ASK existente.

Associando Shapes e Containers

É útil a capacidade de especificar para um Container que tipos de membros ele retornará e aceitará, além da propriedade que ele espera ser usado com recursos desses tipos. Para ativar isso, o Perfil Básico define duas novas propriedades do Container, que são mostradas na Tabela 9.

Propriedades do domínio rdfs:Container
PropriedadeOcorrênciaFaixaComentário
bp:createShape zero ou muitos bp:Shape Uma ou mais Shapes que fornecem informações sobre os formatos de dados esperados dos recursos que podem ser postados para que o Contêiner crie novos membros.
bp:readShape zero ou muitos bp:Shape Uma ou mais Shapes que fornecem informações sobre os formatos de dados esperados dos recursos que podem ser encontrados como membros do Contêiner.
Os contêineres frequentemente incluem propriedades da sua própria postagem e inserem recursos (data de criação, data de modificação, criador), e são úteis para clientes que sabem o que esses podem ser.

Conclusão

Acreditamos que chegar a um Perfil Básico simples permitirá uma adoção mais ampla dos princípios do Linked Data para integração de aplicativos. Será necessário o desenvolvimento adicional de alguns dos conceitos para executar tal perfil. A intenção deste artigo é iniciar o desenvolvimento muito necessário de especificações que preencherão essa lacuna.


Agradecimentos

Agradeço a Arthur Ryman, Arnaud Le Hors e John Arwe, e outros, pela revisão, feedback e um pouco deste conteúdo.

Recursos

Aprender

Obter produtos e tecnologias

  • Faça download de uma versão gratuita do software Rational.
  • Avalie outros produtos de software da IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-a on-line, use-a em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=781941
ArticleTitle=Rumo a um Perfil Básico do Linked Data
publish-date=12222011