HCLSIG/UriWorkshop

From W3C Wiki

URI Workshop

This page was intended for a URI workshop which has since morphed into a Shared Names (or maybe Common Names?) workshop.

Requirements

  • persistence strategy [alanR, jar]
  • redundancy [alanR, jar]
  • maintained [alanR, jar]
  • replic-able [alanR, jar]
  • HTTP resolution yields RDF description [summarized by ericP]

Technical Proposals

Shared Names PURLs (dbxrefs?)

Shared Names assumes that Semantic Web deployment will be improved by solving both the technical and social challenges which currently prevent organizations from sharing identifiers. In order to take advantage of dereferencable identifiers, potential data publishers much have confidence in the custodians of the dererencing service. Technically, Shared Names currently promotes the "slash" approach, and provides an analog to à la XLink's Link Groups.

Shared Names specifically addresses identifying database records and their representations. For a given record R,

GET R; Accept: application/rdf+xml yields 303 page with:

<?xml-stylesheet type="text/xsl" href="thisRDFtoHTML.xsl"?>
<rdf:RDF>
<db1:db1_record_type rdf:about="R"> <!-- how is this type used? -->
  <rdfs:label>Record R in db1</rdfs:label>
  <rdfs:comment>unencoded identifier for a record R in db1.</rdfs:comment>
  <x:hasRepresentation>
    <x:XMLrepresentation>
      <x:providedBy rdf:resource="db1"/>
      <x:resource rdf:resource="db1/xml/R"/>
    </x:XMLrepresentation>
  </x:hasRepresentation>
  <x:hasRepresentation>
    <x:RDFDrepresentation>
      <x:providedBy rdf:resource="db1"/>
      <x:resource rdf:resource="db1/rdf/R"/>
    <x:XMLrepresentation>
  <x:hasRepresentation>
</db1:db1_record_type>
</rdf:RDF>


Alternate Representations

The inclusion of an xml-stylesheet reference effectively provides an HTML representation of the data. For example, the above would use


 <thisRDFtoHTML.xsl>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <html><head><title>
    <xsl:value-of select="rdfs:label"/>
    </title><head><body>
    </body></html>
  </xsl:template>
  <xsl:template match="db1:db1_record_type/">
    <h1><xsl:value-of select="rdfs:label"/></h1>
    ...
  </xsl:template>
  ...
  </xsl:stylesheet>

to generate specific HTML for this page. As the XML representation evolves, it is necessary to co-maintain the stylesheet.

Leaning on an XML stylesheet requires the origin document be in XML, and restrics to a single alternative representation. @@check@@

Direct Names

The Linked Open Data approach has focused on "hash" (instead of "slash"). "Object identifiers" are distinguished from web resources which describe them by adding '#'<identifier> to the resource. Pages can be made to hold clouds of objects associated with a record (of a reasonable size), e.g.

 http://purl.uniprot.org/uniprot/P04637#theProtein
 http://purl.uniprot.org/uniprot/P04637#citation7
 http://purl.uniprot.org/annotation/VAR_045350#annot

while ontologies favor clouds of properties relevent to a particular domain or specialization. This principle technical distinction between Direct names and the current Shared Names use of 303s is that Direct names use e.g. #annot to denote a real-world object while the slash approach uses somewhat novel interpretations of the HTTP respond code [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 303 See Other]. Further, the 303 approach endorsed by Shared Names relies on XSL to provide alternate representations

Direct + "link groups"

@@ChrisB, RCyganiac, Kingsley might have opinions here.@@

GET R; Accept: application/rdf+xml yields 303 page with:

#R a db1:db1_record_type ;
   rdfs:label "Record R in db1" ;
   rdfs:comment "unencoded identifier for a record R in db1." ;
   x:hasRepresentation [ @@replace with specifics@@
     a x:XMLrepresentation; 
     x:providedBy <db1> ;
     x:resource   <db1/xml/R>
   ] ;
   x:hasRepresentation [
     a x:RDFDrepresentation ;
     x:providedBy <db1> ;
     x:resource   <db1/rdf/R>
   ] .


@@LOD have some inertia here -- get details@@

Alternate Representations

HTTP Conneg allows the server to provide "alternate representations" in any format. Data generators are expected to keep all representations equivalent.

Direct + seeAlso

This effectively a way to *not* need shared names. Specifically, Scalablity of this approach vs. an approach with shared names has not been explored. @@but there's some data somewhere@@.