--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/rdf-layers/index.html Tue May 01 23:15:46 2012 -0400
@@ -0,0 +1,648 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>RDF Data Layers and Datasets</title>
+ <style type="text/css">
+.figure { font-weight: bold; text-align: center; }
+table.xsd-types td, table.xsd-types th { border: 1px solid #ddd; padding: 0.1em 0.5em; }
+ </style>
+ <script src='../ReSpec.js/js/respec.js' class='remove'></script>
+ <script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "rdf-layers",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2012",
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+// previousPublishDate: "2004-02-10",
+// previousMaturity: "REC",
+
+ // if there a publicly available Editor's Draft, this is the link
+//@@@
+ edDraftURI: "http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-layers/index.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if there is an earler version of this specification at the Recommendation level,
+ // set this to the shortname of that version. This is optional and not usually
+ // necessary.
+ // prevRecShortname: "rdf-concepts",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dvcs.w3.org/hg/rdf/raw-file/default/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "TBD", url: "",
+ company: "", companyURL: "",
+ },
+ ],
+ otherContributors: {
+ "Initial sketch by": [
+ { name: "Sandro Hawke", url:"http://www.w3.org/People/Sandro",
+ company:"W3C", companyURL: "http://www.w3.org", }
+ ],
+ },
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "RDF Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/rdf-wg/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-rdf-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/46168/status",
+
+ // if this parameter is set to true, ReSpec.js will embed various RDFa attributes
+ // throughout the generated specification. The triples generated use vocabulary items
+ // from the dcterms, foaf, and bibo. The parameter defaults to false.
+ doRDFa: true,
+ };
+
+// @@@ A number of references have been patched into the local berjon.biblio and need to be added to the global biblio in CVS:
+ </script>
+ </head>
+
+ <body>
+
+<section id="abstract">
+ <p>This specification introduces the notion of RDF <i>data
+ layers</i>—places to store RDF triples—and defines a
+ set of languages for expressing information about them. Examples of
+ data layers include: an HTML page with embedded RDFa or microdata, a
+ file containing RDF/XML or Turtle data, and a SQL database viewable
+ as RDF using R2RML. The term "layer" is a metaphor: we imagine a
+ layer as transparent surfaces on which RDF graphs can be drawn and
+ then easily combined, still retaining their own identity and
+ properties. RDF data layers are a generalization of SPARQL's named
+ graphs, bringing standard semantics to systems which manage multiple
+ collections of RDF data. </p>
+</section>
+
+
+<section class="informative">
+ <h2>Introduction</h2>
+
+
+ <p>An RDF data layer is a collection of RDF Triples, or a place to
+ store triples. This trivial concept is an important building
+ block for the Semantic Web. RDF Layers are what some people have
+ called Named Graphs, but they are different from both RDF Graphs
+ and Named Graphs as those terms are defined in existing W3C
+ specifications.</p>
+
+ <p>The difference between RDF Layers and RDF Graphs is that while
+ they are both sets of triples, RDF Layers can conceptually change
+ over time and have an identity separate from their contents. RDF
+ Graphs, in contrast, are pure mathematical sets, so it makes no
+ sense to talk about them "changing", and two graphs which contain
+ the same triples are by definition the same graph. RDF layers are
+ different; they keep their own identify even when the happen to
+ contain exactly the same triples. This distinction is important
+ when there is data (or metadata) about the set of triples; if the
+ metadata is about a set with its own identity, an RDF Layer should
+ be used instead of a Graph.</p>
+
+ <p>The name "layer" is chosen to evoke the image of a transparent
+ surface on which an RDF Graph can be temporarily drawn and then
+ easily aligned with other layers to make a larger, combined
+ graph. Sometimes we work with the combined graph, but when we want
+ to, we can still separate the layers. This is particularly
+ important if the data come from different sources which might
+ potentially update their contribution; we need to be able to erase
+ and redraw just their layer.</p>
+
+ <img src="layers.jpg" />
+
+ <p class="note">Eric suggests that only the arcs should be drawn
+ on the layers; the nodes are fundamental, underneath, projecting
+ up through all the layers.</p>
+
+
+</section>
+
+<section>
+ <h2>Terminology</h2>
+
+ <p>TBD</p>
+
+ <p>A "Layer Switch" is a resource which acts as a different layer
+ based on some client context, such as the user identity. Systems
+ which use layer switches SHOULD also define working URLs for each of
+ the layers the switch can act as, and SHOULD provide the URL of the
+ layer used during any http transaction using the Content-Location
+ header. For example <tt>http://example.org/my-account-balance</tt>
+ might return the account balance of the logged-in user. If the user
+ is logged in as "alice", the system might return a Content-Location
+ of <tt>http://example.org/my-account-balance?user=alice</tt>. For
+ alice, that later URL would work as well; for other users it would
+ give <tt>403 Forbidden</tt>.
+
+</section>
+
+<section>
+ <h2>Use Cases</h2>
+
+ <p>TBD. See <a href="#detailed-example">Detailed Example</a> for now.</p>
+
+</section>
+
+
+<section>
+ <h2>Datasets</h2>
+
+ <section id="section-multigraph">
+ <h3>Formal Definition</h3>
+
+ <p class="note">Should this quote or replace this text from RDF
+ Concepts?</p>
+
+ <p>An <dfn>RDF Dataset</dfn> is a collection of
+ <a>RDF graphs</a> and comprises:</p>
+
+ <ul>
+ <li>Exactly one <dfn>default graph</dfn>, being an <a>RDF graph</a>.
+ The default graph does not have a name and MAY be empty.</li>
+ <li>Zero or more <dfn>named graphs</dfn>.
+ Each named graph is a pair consisting of an <a>IRI</a>
+ (the <dfn>graph name</dfn>), and an <a>RDF graph</a>.
+ Graph names are unique within an RDF dataset.</li>
+ </ul>
+
+ <div class="issue">
+ <p>The design presented here should be considered a straw man proposal at this point. It is based on RDF Datasets as <a href="http://www.w3.org/TR/sparql11-query/#rdfDataset">defined in SPARQL 1.1</a>.</p>
+ </div>
+
+</section>
+</section>
+
+<section id="syntax">
+ <h2>Dataset Languages</h2>
+
+ <section>
+ <h3>N-Quads</h3>
+
+ </section>
+
+
+ <section>
+ <h3>TriG</h3>
+
+ </section>
+
+
+ <section>
+ <h3>Turtle in HTML</h3>
+
+ <div class="note">
+ <p>This is higly speculative. An interesting idea.</p>
+
+ <p>The key challenge is: can we get everyone to agree that when
+ the script tag has an id attribute, those contents are
+ <em>not</em> asserted? Or maybe we need something like
+ class="unasserted"... but do we have the right to say either of
+ those things? Maybe in the Turtle spec...</p>
+ </div>
+
+ <p>When text/turtle is used inside HTML script tags, if the script
+ tag has an id attribute, then that content goes into a named graph
+ (with its name being that section URL). The rest goes into the
+ default graph.</p>
+
+ </section>
+
+
+
+</section>
+
+<section>
+ <h2>Semantics</h2>
+
+ <p>Formally, a layer is a function from points in time to RDF
+ Graphs. At any given point in time, there is one RDF Graph "in"
+ that layer, or the layer is undefined at that point in time.</p>
+
+ <p>SPARQL defines a <a
+ href="http://www.w3.org/TR/sparql11-query/#rdfDataset">Dataset</a>
+ as a structure consisting of a "default" graph and a set of (name,
+ graph) pairs. We now give this structure declarative semantics,
+ allowing dataset to be used as logical statements, like RDF Graphs.
+ We define a dataset as being true if and only if (1) its default
+ graph is true, and (2) for every (<i>name</i>, <i>graph</i>) pair in
+ the dataset, the layer denoted by <i>name</i> contains every triple
+ in <i>graph</i>.</p>
+
+</section>
+
+<section>
+ <h2>Conformance</h2>
+
+ <p>Something like: If a layer has a URL, and you get a 200 response
+ dereferencing that URL, the the response MUST be a serialization of
+ the triples on that layer, give or take synchronization (caching)
+ issues. </p>
+
+ <p>What else?</p>
+
+</section>
+
+<section class="informative">
+ <h2>Detailed Example</h2>
+
+ <p>This section shows, with some detail, several ways layers can be
+ used to help build a federated information system.</p>
+
+ <section>
+ <h3>A Federated Phonebook, in Layers</h3>
+
+ <p>As a first example of how to use layers, consider an
+ organization which has 25 different divisions around the world,
+ each with its own system for managing the list of its employees
+ and their phone numbers. The parent organization wants to create
+ a unified "HQ" directory with all this information. With their HQ
+ directory, they will be able to look up an employee's phone number
+ without first knowing the employee's division. </p>
+
+ <p>They decide to use RDF layers. Each division is asked to
+ publish its phonebook on an internal website, in a W3C-Recommended
+ RDF syntax, using <a href="http://www.w3.org/TR/vcard-rdf/">the
+ vcard-rdf vocabulary</a>. Each division submits the URL at which
+ this file will appear. For example, the uswest division might
+ publish the RDF version of its phonebook at
+ <tt>http://uswest.internal.example.com/employees.rdf</tt> and the
+ Japan division might publish theirs at
+ <tt>http://ja.example.com/hr/data/export371</tt>. The URL itself
+ doesn't matter, but the division must be able to maintain the
+ content served there and HQ must be able to easily fetch the
+ content. </p>
+
+ <p>The HQ staff assembles this list of 25 feed URLs and puts them
+ into the default graph of a SPARQL database, so the database looks
+ like this: </p>
+
+<pre> @prefix hq: <<a href="http://example.com/hq-vocab#">http://example.com/hq-vocab#</a>>.
+ # default graph
+ {
+ hq:parentCo hq:division hq:div1, hq:div2, hq:div3, ...
+ <<a href="http://uswest.internal.example.com/employees.rdf">http://uswest.internal.example.com/employees.rdf</a>>
+ hq:feedFrom hq:div1.
+ <<a href="http://ja.example.com/hr/data/export371">http://ja.example.com/hr/data/export371</a>>
+ hq:feedFrom hq:div2.
+ ...
+ }
+</pre>
+<p>Then they write a simple Web client which looks in the database for
+those feed URLs, dereferences them, and parses the RDF. It then puts
+the parse-result into the database in a layer whose name is the same as the
+name of the feed. This makes sense, because in this deployment each
+feed is considered to be a layer; the name of the feed is the same as
+the name of the layer. The HQ client is copying data about the layer
+from the division databases to the HQ database, but it's still the
+same information about the same layers.
+</p>
+
+<p>For performance reasons, the client is designed to use HTTP
+caching information. This will allow it to efficiently re-fetch the
+information only when it has changed. To make this work, the client will need
+to store the value of the "Last-Modified" HTTP header and also store
+(or compute, in some configurations) the value of the "Expires" header.
+</p>
+
+<p>In the end, the database looks something like this:
+</p>
+<pre> @prefix hq: <<a href="http://example.com/hq-vocab#">http://example.com/hq-vocab#</a>>.
+ @prefix v: <<a href="http://www.w3.org/2006/vcard/ns#">http://www.w3.org/2006/vcard/ns#</a>>.
+ @prefix ht: <<a href="http://example.org/http-vocab#">http://example.org/http-vocab#</a>>.
+ <<a href="http://uswest.internal.example.com/employees.rdf">http://uswest.internal.example.com/employees.rdf</a>> {
+ # an employee
+ [ a v:VCard
+ v:fn "John Wayne" ;
+ v:email "wayne@uswest.example.com" .
+ v:tel [ a v:Work, v:Pref ;
+ rdf:value "+213 555 5555" ]
+ ]
+ # another employee
+ ...
+ }
+ <<a href="http://ja.example.com/hr/data/export371">http://ja.example.com/hr/data/export371</a>> {
+ # an employee
+ [ a v:VCard
+ v:fn "Toshiro Mifune" ;
+ v:email "wayne@uswest.example.com" .
+ v:tel [ a v:Work, v:Pref ;
+ rdf:value "+81 75 555 5555" ]
+ ]
+ # another employee
+ ...
+ }
+ ... other divisions
+ # default graph, with all our metadata
+ {
+ hq:parentCo hq:division hq:div1, hq:div2, hq:div3, ...
+ # stuff we need to know the efficiently keep our copy in sync
+ <<a href="http://uswest.internal.example.com/employees.rdf">http://uswest.internal.example.com/employees.rdf</a>>
+ hq:feedFrom hq:div1;
+ ht:last-modified "2012-03-14T02:22:10"^^xs:datetime;
+ ht:expires "2012-04-29T00:15:00"^^xs:datetime.
+ <http://ja.example.com/hr/data/export371>
+ hq:feedFrom hq:div2;
+ ht:last-modified "2012-04-01T22:00:00"^^xs:datetime;
+ ht:expires "2012-04-29T00:35:00"^^xs:datetime.
+ }
+</pre>
+<p>The URL of each layer appears in four different roles in this example:
+</p>
+
+<p>1. It is used as a label for a graph. Here, it says which layer the
+triples in that graph are in. That is, the triples about employee
+"John Wayne" are in the layer named
+"http://uswest.internal.example.com/employees.rdf". Information about
+what triples are in that layer originates in the master database for
+each division, then is copied to the slave database at HQ.
+</p>
+
+<p>2. It is used as the subject of an hq:feedFrom triple. This
+information is manually maintained (or maintained through a corporate
+WebApp) and used to help guide the HQ fetching client. Because in
+this deployment we are equating layers and feeds, the name of the
+layer is also the URL of the feed.
+</p>
+
+<p>3. It is used as the subject of an ht:last-modified triple. The
+information in this triples comes from the HTTP Last-Modified header.
+The meaning of this header in HTTP lines up well with its intuitive
+meaning here: this is the most recent time the set of triples in this
+layer changed. (This header can be used during a refresh, with the
+If-Modified-Since headers, to make a client refresh operation very
+simple and fast if the data has not changed.)
+</p>
+
+<p>4. It is used as the subject of an ht:expires triple. This
+information also comes from HTTP headers, although some computation
+may be needed to turn it into the absolute datetime form used here.
+Strictly speaking, what is expiring at that time is this copy of the
+information about the layer, not the layer itself. This slight
+conflation seems like a useful and unproblematic simplification.
+</p>
+
+<p>Given this design, it is straightforward to write SPARQL queries to
+find the phone number of an employee, no matter what their division.
+It is also easy to find out which layer is about to
+expire or has expired and should be refreshed soon.
+</p>
+
+<p>Some alternative designs:
+</p>
+<ul><li> Divisions could push their data, instead of waiting to be polled. That is, the divisions could be given write access to the HQ database and do SPARQL UPDATE operations to their own layers. This is simpler in some ways but may require more expertise from people in each division. It also requires trusting people in each division or having a SPARQL server that can be configure to grant certain users write access to only certain layers. This also turns HQ into more of a bottleneck and single-point of failure. With the polling approach, other systems could be given the list of feed URLs and then offer an alternative combined directory, or use the same data for other purposes, without any involvement from the divisions.
+</li></ul>
+<ul><li> The HQ client could fetch or query all the divisions at query time, rather that gathering the data in advance. This might use the <a href="http://www.w3.org/TR/sparql11-federated-query/">SPARQL 1.1 Federated Query</a> features. Which approach is superior will depend on the particulars of the situation, including how large the data is, how often it changes, and the frequency of queries which need data from different divisions. Federated Query would probably not be ideal for the situation described here, but should be considered by people building systems like this.
+</li></ul>
+
+ </section>
+ <section>
+ <h3>Cache Management Using HTTP</h3>
+
+ <p class="note">Factor out the Last-Modified and Expires stuff,
+ from the previous section, and put it here.</p>
+
+ <p class="note">Show that instead of expires like this, it could
+ be done with [an Expiration; inDataset <>; atTime ...;
+ ofLayer]</p>
+
+
+ </section>
+
+
+ <section>
+ <h3>Keeping Derived Information Separate</h3>
+
+ <p>The Federated Phonebook example shows several features of
+ layers, but leaves out a few. In this example we will show the
+ use of privately-named layers and of sharing blank nodes between
+ layers.</p>
+
+ <p>The scenario is this: some divisions use only vcard:n to
+ provide structured name information (keeping given-name and
+ family-name separate), while others use only vcard:fn to provide a
+ formatted-name (with both parts combined). The politics of the
+ organization make it impractical to tell the divisions to all use
+ vcard:n or all use vcard:fn, or both. Meanwhile, several
+ different tools are being written to use this employee directory,
+ including a WebApp, a command-line app, and apps for several
+ different mobile platforms. Does each app have to be written to
+ understand both vcard:n and vcard:fn? </p>
+
+ <p>HQ decides the solution is for them to run a single process
+ (which they call "namefill") to normalize the data, making
+ sure that every entry has both vcard:n and vcard:fn data, no
+ matter what the division provided. The process is fairly simple;
+ after any layer is reloaded, a program runs which looks at that
+ layer and fills in the missing name data. </p>
+
+ <p>Because of the tricky politics of the situation, however, HQ
+ decides it would be best to keep this "filled in" data separate.
+ In some cases their program might not fill in the data properly.
+ For example, how can a program tell from the formatted name
+ "Hillary Rodham Clinton" that "Rodham Clinton" is the family-name?
+ The solution is to keep the output of the program in a separate
+ layer, so clients (and people trying to debug the system) can tell
+ this filled-in data did not come from the division itself. </p>
+
+ <p>The result is a dataset like this:
+ </p>
+
+ <pre class="example">@prefix hq: <http://example.com/hq-vocab#>.
+@prefix v: <http://www.w3.org/2006/vcard/ns#>.
+@prefix ht: <http://example.org/http-vocab#>.
+ <http://uswest.internal.example.com/employees.rdf> {
+ # an employee
+ _:u331 a v:VCard
+ v:fn "John Wayne" ;
+ v:email "wayne@uswest.example.com" .
+ v:tel [ a v:Work, v:Pref ;
+ rdf:value "+213 555 5555" ].
+ ...
+ }
+ hq:namefill602 {
+ _:u331 v:n [
+ v:family-name "Wayne";
+ v:given-name "John"
+ ]
+ }
+ ...
+ # default graph has metadata
+ {
+ hq:parentCo hq:division hq:div1, hq:div2, hq:div3, ...
+ <http://uswest.internal.example.com/employees.rdf>;
+ hq:feedFrom hq:div1;
+ hq:namefillLayer hq:namefill602
+ ...
+ }
+</pre>
+
+<p>In serializing this, we needed to introduce a blank node label
+("_:u331"), because that blank node (representing the employee) occurs
+in two different layers.
+</p>
+
+<p>The example also shows the creation of a new layer name
+(hq:namefill602) for the layer filled in by our namefill program. We
+use one new layer for each feed, instead of one layer for all the
+output of the namefill program, so we have less work to do when a
+single feed layer is reloaded.
+</p>
+
+<p>The techniques in this example apply equally well to information that
+is derived as part of logical inference, such as done by an RDFS, OWL,
+or RIF reasoner. In these more general cases, it may be that one
+layer can be used for all derived information, or, at the other end of
+the granularity spectrum, that a new layer is used for the triples
+derived in each step of the process.
+</p>
+
+ </section>
+ <section>
+ <h3>Archiving Data With Static Layers</h3>
+
+ <p>One more variation on the federated phonebook scenario: what if
+ HQ wants to be able to look up old information? For instance,
+ what happens when an employee leaves and is no longer listed in a
+ division phonebook? It could be nice if the search client could
+ report that the employee is gone, rather than leaving people
+ wondering it they've made a mistake with the name. </p>
+
+ <p>To address this, HQ's data-loading client will not simply
+ delete a layer before reloading it. Instead, it will first copy
+ the data to a new, archival layer. After three reloads, the
+ database might look something like this: </p>
+
+<pre class="example">@prefix hq: <http://example.com/hq-vocab#>.
+@prefix hqa: <http://example.com/hq/archive/>
+@prefix v: <http://www.w3.org/2006/vcard/ns#>.
+@prefix ht: <http://example.org/http-vocab#>.
+hqa:0001 {
+ ... oldest version
+}
+hqa:0002 {
+ ... middle version
+}
+<http://uswest.internal.example.com/employees.rdf> {
+ ... current version
+}
+# default graph
+{
+ hqa:0001 hq:startValidTime ...time... ;
+ hq:endValidTime ...time... .
+ hqa:0002 hq:startValidTime ...time... ;
+ hq:endValidTime ...time... .
+ <http://uswest.internal.example.com/employees.rdf>
+ hq:snapshot hqa:0001, hqa:0002.
+ ....
+}
+</pre>
+
+<p>This model uses static layers, whose contents are never supposed to
+change. (They are still different from RDF Graphs in that they retain
+their own identity; two static layers containing the same triples can
+have different metadata.) For each static layer, we record the time
+interval for which it was current (its
+<a href="http://en.wikipedia.org/wiki/Valid_time">valid time</a>) and what it is a
+snapshot of.
+</p>
+
+<p>The URL for each static layer is generated by incrementing a sequence
+counter. To follow Linked Data principles, HQ should provide RDF
+serializations of the contents of each layer in response to
+dereferences of these URLs. (When the state of layers is
+obtained like this, with separate HTTP responses for each one, a blank
+node appearing on multiple layers will appear as multiple blank nodes.
+For blank node sharing to work, the dataset which serializes the
+contents of all the relevant layers must be transmitted or queried as
+a unit.)
+</p>
+
+<p>There is nothing about this architecture that prevents the archival
+data from being modified. The people maintaining the system simply agree
+not to change it. If this is not sufficient, other approaches could
+be designed, such as generating the URL using a cryptographic hash of
+the layer contents.
+</p>
+
+<p>Another variant on this design is to put the feed data directly into
+an archival layer, instead of having the current data in a the same
+layer as the feed.. If the data is likely to grow stale (not be kept
+in sync with the feed master data), this may be a better approach,
+reducing the possibility of people unknowingly using outdated
+information.
+</p>
+
+</section>
+</section>
+
+<section>
+ <h2>Issues</h2>
+
+ <p>Do the named graphs in a dataset include all the triples in the
+ layers with those names, or only some of them? Aka partial-graph or
+ complete-graph semantics.</p>
+
+ <p>Can blank nodes be shared between layers?</p>
+
+ <p>What do we do about RDF reification. Should we try to fix it to
+ be talking about layers?</p>
+
+ <p>How should we talk about change-over-time? The archiving example
+ gets into it right now.</p>
+
+
+</section>
+
+
+<section class="appendix informative" id="changes">
+ <h2>Changes</h2>
+ <ul>
+ <li>2012-05-01: Starting with a little text from RDF Concepts, a few ideas, and the text from <a href="http://www.w3.org/2011/rdf-wg/wiki/Layers">Layers</a></li>
+ </ul>
+</section>
+
+
+<section id="references">
+</section>
+
+ </body>
+</html>
+