Skip to content

Commit

Permalink
Merge branch 'w3c-gh-pages' into gh-pages
Browse files Browse the repository at this point in the history
  • Loading branch information
@jakubklimek
jakubklimek committed Jul 19, 2019
2 parents 4f6dea8 + 6d352d1 commit be6eedd
Show file tree
Hide file tree
Showing 7 changed files with 902 additions and 681 deletions.
16 changes: 9 additions & 7 deletions conneg-by-ap/config.js
View file
@@ -1,8 +1,10 @@
var respecConfig = {
specStatus: "FPWD",
specStatus: "WD",
shortName: "dx-prof-conneg",
edDraftURI: "https://w3c.github.io/dxwg/conneg-by-ap/",
previousURI: "https://w3c.github.io/dxwg/conneg-by-ap/",
previousPublishDate: "2018-12-18",
previousMaturity: "FPWD",
prevRecURI: "https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/",
testSuiteURI: "https://github.com/CSIRO-enviro-informatics/prof-conneg-test-suite",
implementationReportURI: "https://github.com/CSIRO-enviro-informatics/prof-conneg-implementations",
canonicalURI: "TR",
Expand Down Expand Up @@ -72,19 +74,19 @@ var respecConfig = {
"Antoine Isaac",
"Nicholas J. Car"
],
href: "https://www.w3.org/TR/profile-guidance/",
href: "https://w3c.github.io/dxwg/profiles/",
title: "Profile Guidance",
date: " 2018-12-31",
date: " 2019-04-24",
status: "W3C Editor's Draft"
},
"PROF-IETF": {
authors: [
"L. Svensson",
"R. Verborgh"
],
href: "https://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema/",
title: "Negotiating Profiles in HTTP",
date: " 2017-10-24",
href: "https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation",
title: "Indicating and Negotiating Profiles in HTTP",
date: " 2019-07-11",
status: "IETF Internet Draft"
},
"PROF": {
Expand Down
108 changes: 35 additions & 73 deletions conneg-by-ap/index.html
View file
Expand Up @@ -24,11 +24,10 @@ <h3>Overview of DXWG documents on profiles</h3>
Some of the documents are general whereas others are technology-specific:
</p>
<ul>
<li>[[PROF-GUIDANCE]] the top-level general recommendations and guidance on profiling.
It gives an overview of all DXWG documents on profiles and is the recommended starting point</li>
<li>[[PROF]] an RDF vocabulary that describes profiles and related resources</li>
<li><strong>[PROF-CONNEG] this document, specific guidance on how to negotiate for Internet resource content using profiles</strong></li>
<li>[[PROF-IETF]] an <a href="http://www.ietf.org">IETF</a> <a href="http://www.ietf.org/standards/ids/">Internet-Draft</a> defining HTTP Headers for HTTP content negotiation by profile</li>
<li>It is also planned to provide [[PROF-GUIDANCE]] as general recommendations and guidance on profiling.</li>
</ul>
</section>
</section>
Expand All @@ -51,14 +50,14 @@ <h2>Introduction</h2>
<p>
When online information about a resource adheres to one or more profiles, methods described here allow
clients to list those profiles and request content according to one or more of them in order of preference.
For example, information about an online book might adhere to the Dublin Core Terms [[DCTERMS]] metadata
specification with each field, such as <em>title</em>, <em>description</em>, <em>author</em> etc.,
being defined and formatted according to various Dublin Core elements (<code>dct:title</code>,
<code>dct:description</code> &amp; <code>dct:creator</code>, respectively). Then, a request for the information about this
book may ask for the list of profiles according to which the metadata is available, or it may ask specifically for a response adhering to the
Dublin Core Terms. When no profile or an unsupported profile is requested, a server returns default content, that
For example, a catalog may offer a dataset description using alternative representations using [[VOID]], [[VOCAB-DATA-CUBE]] and [[VOCAB-DCAT]]. Furthermore, the [[VOCAB-DCAT]] representation might conform to the [[DCAT-AP]] profile, the [[GeoDCAT-AP]] profile and also an organisation specific profile "MyOrgDCATProfile" which constrain various elements. These profiles may be related - for example "MyOrgDCATProfile" may be a further profile of [[GeoDCAT-AP]].
A request for the information about this
dataset description resource may ask for the list of profiles available, or it may ask specifically for a response adhering to, for example [[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default content, that
is, content conforming to the default profile supported by the server.
</p>
<p class="issue" data-number="990">
Where documents contain data specifications (specifying requirements for certain types of data) in addition to other content, such as recommendations, annotations, usage notes) then this can be accomodated by publishing explicit identifiers for each section that represents a data specification that can be conformed to. All such specifications can be regarded as profiles, and communities may choose to reference the document as a profile provided that it defines the means to determine conformance to the document as a whole.
</p>
<p>
When selecting a content negotiation mechanism, an Internet client may use the HTTP protocol but it may also use
other methods for providing instructions to a server,
Expand All @@ -68,24 +67,24 @@ <h2>Introduction</h2>
as when manually entering requests into web browsers. This document also provides guidance for both HTTP and non-HTTP methods
of content negotiation and ensures they all adhere to a single functional specification, ensuring their functional equivalency.
</p>
<p>
<!-- <p>
Guidance for the creation of <a>profile</a>s is provided in the [[PROF-GUIDANCE]] document created
by the Dataset Exchange Working Group (DXWG).
</p>
</p> -->
<p>
Describing the parts of profiles and their relation to other profiles is the function of the Profiles Vocabulary
[[PROF]], also produced by the DXWG.
</p>
</section>
<section id="conformance">
<h2>Conformance</h2>
<p>
For the purpose of compliance, the normative sections of this document are
<a href="#definitions">Section 3</a>,
<a href="#abstractmodel">Section 6</a>,
<a href="#realizations">Section 7</a> and
<a href="#testsuites">Section 8</a>.
</p>
<p>NB Profiles and specifications embody their own notions of conformance (of data), which are out of scope for this document.</p>
</section>
<section id="definitions">
<h2>Definitions</h2>
Expand Down Expand Up @@ -321,7 +320,7 @@ <h3>OAI-PMH</h3>
specifies Query String Argument-based "Protocol Requests and Responses" that allow clients of
<em>Data Providers</em> to: retrieve the metadata formats available from a repository
(<code>ListMetadataFormats</code>); retrieve metadata for an identified record (<code>GetRecord</code>),
according to an identified metadata profile; perform a number of other repository interrogation tasks; and to
according to an identified metadata profile (<code>metadataPrefix</code>); perform a number of other repository interrogation tasks; and to
harvest collections of record's metadata, filtered by parameters such as modified date.
</p>
<p>
Expand All @@ -341,7 +340,7 @@ <h3>Catalogue Service for the Web (CSW)</h3>
as well as other types of resources. Besides supporting common functions such as free-text and faceted search, CSW supports the retrieval of metadata according to a given metadata schema and format, indicated respectively by using <code>outputSchema</code> and <code>outputFormat</code> query parameters. Commonly supported metadata schemas are [[DC11]], and [[ISO-19115]], and the default format is XML. A given CSW instance's supported metadata schemas and formats are described in the service "capabilities" -- a machine-readable description of the service interface, that is returned via a <code>GetCapabilities</code> request.
</p>
<p>
Notably, CSW theoretically supports HTTP content negotiation for the metadata format, and the specification defines a conflict resolution mechanism for requests where this information is specified both via HTTP <code>Accept</code> headers and the <code>outputFormat</code> parameter (see <a href="http://docs.opengeospatial.org/is/12-176r7/12-176r7.html#8">Section 6.2</a> of the <cite>OGC CSW 3.0 specification - HTTP Protocol Binding</cite>).
Notably, CSW theoretically supports HTTP content negotiation for the metadata format, and the specification defines a conflict resolution mechanism for requests where this information is specified both via HTTP <code>Accept</code> headers and the <code>outputFormat</code> parameter (see Section 6.2 of the <a href="http://docs.opengeospatial.org/is/12-176r7/12-176r7.html">OGC CSW 3.0 specification - HTTP Protocol Binding</a>).
</p>
</section>
</section>
Expand Down Expand Up @@ -528,6 +527,22 @@ <h3>Hypertext Transfer Protocol Headers</h3>
<code>Accept-Profile</code> and <code>Content-Profile</code>
that are to be defined in an upcoming Internet-Draft [[PROF-IETF]].
</p>
<p>
Although servers are free to implement negotiation as they see fit,
if the User Agent sends an <code>Accept-Profile</code> header,
they SHOULD consider representations not conforming to any of the listed profiles
as non-interpretable by the client.
This means that a representation that conforms to a listed profile,
but has a low preference score on other dimensions,
SHOULD be considered as more desired than
a representation with a higher preference score on other dimensions
but that does not conform to any listed profile.
If no <code>Accept-Profile</code> header preference is given,
the profile dimension SHOULD be ignored for negotiation purposes.
Nonetheless, in all cases,
the server's response SHOULD contain a <code>Content-Profile</code> header
listing the URIs of all profiles to which it knows the representation conforms.
</p>
<div class="issue" data-number="500"></div>
<section id="listprofileshttp">
<h3>list profiles</h3>
Expand Down Expand Up @@ -694,7 +709,7 @@ <h3>get resource by profile</h3>
</section>
</section>
<section id="qsa">
<h2>URL Query String Arguments</h2>
<h3>URL Query String Arguments</h3>
<div class="issue" data-number="594"></div>
<div class="issue" data-number="538"></div>
<p>
Expand Down Expand Up @@ -897,9 +912,9 @@ <h2>Acknowledgements</h2>
</p>
</section>
<section id="changes" class="informative">
<h2>Changes</h2>
<p>Changes since the <a href="https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/">18 December 2018 Working Draft</a> are:</p>
<ul>
<h2>Changes</h2>
<p>Changes since the <a href="https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/">18 December 2018 Working Draft</a> are:</p>
<ul>
<li>
Added Related Work subsections for
Linked Data APIs (<a href="https://github.com/w3c/dxwg/issues/383">Issue 383</a>),
Expand All @@ -921,7 +936,7 @@ <h2>Changes</h2>
<li>Added a not about length restrictions in URLs to the <a href="#qsa">QSA</a> section.
(<a href="https://github.com/w3c/dxwg/issues/592">Issue 592</a>)</li>
</ul>
</section>
</section>
<section id="security_and_privacy" class="informative">
<h2>Security and Privacy</h2>
<p>
Expand All @@ -942,7 +957,7 @@ <h2>Security and Privacy</h2>
<section id="appendices" class="appendix">
<h2>Appendices</h2>
<section id="requirements">
<h2>Requirements</h2>
<h3>Requirements</h3>
<p>
This section lists, and then addresses, individual requirements that the Dataset Exchange Working Group
considered important for content negotiation by profile.
Expand All @@ -957,59 +972,6 @@ <h2>Requirements</h2>
individual listings of requirements; they may be subsumed into the flowing txt of the document.
</p>
</div>
<div class="issue" data-number="72"></div>
<div class="req-response">
<p class="respTitle">RESPONSE FOR Req. 72</p>
<p>

</p>
</div>
<div class="issue" data-number="73"></div>
<div class="req-response">
<p class="respTitle">RESPONSE FOR Req. 73</p>
<p>
This requirement is addressed by suggesting how an Internet resource in general, rather than specifically a
<code>dcat:Dataset</code> or <code>dcat:Distribution</code> should list profiles it implements. A DCAT-
specific solution should not be any different from the general case.
</p>
<div class="note" title="">Profile definition and constraints on properties are not addressed here. See
[[PROF-GUIDANCE]].</div>
<p>
This requirement is taken to mean "create a way to list the profiles implemented by a Internet resource for
<em>humans</em> and <em>machines</em> to use". For the former (humans), the options are:
</p>
<ul>
<li>
discovery via HTML representation
<ul>
<li>see [[PROF-GUIDANCE]]</li>
<li>an approach suggested is to provide an <em>alternate view</em> resource for the original
resource located at <code>RESOURCE_URL + ?_view=alternates</code> which lists, at a minimum, the
<em>profiles</em>, <em>media types</em> (formats) &amp; <em>languages</em> available, as per the
<em>alternate views</em> guidance.
</li>
</ul>
</li>
</ul>
<div class="issue" data-number="392"></div>
<p>For the latter (machines):</p>
<ul>
<li>
discovery via HTTP
<ul>
<li>see [[PROF-IETF]]</li>
<li>HTTP mechanics are described that allow clients to negotiate with servers for profile listings</li>
</ul>
</li>
<li>
discovery via RDF graph
<ul>
<li>see [[PROF]]</li>
</ul>
</li>
</ul>
<div class="issue" data-number="393"></div>
</div>
<div class="issue" data-number="74"></div>
<div class="req-response">
<p class="respTitle">RESPONSE FOR Req. 74</p>
Expand Down Expand Up @@ -1098,7 +1060,7 @@ <h3>Issue Summary</h3>
<!-- A list of issues will magically appear here -->
</section>
<section id="extra-issues" class="appendix">
<h2>Additional Issues</h2>
<h3>Additional Issues</h3>
<p><em>This section will be removed in a later version of this document.</em></p>
<p>Additional Issues related to this document and not yet placed within it are listed at the:</p>
<ul>
Expand Down
21 changes: 19 additions & 2 deletions dcat/config.js
View file
@@ -1,5 +1,6 @@
var respecConfig = {
// preProcess: [dfn_index],
// subtitle: "Version 2",
specStatus: "ED",
shortName: "vocab-dcat-2",
canonicalURI: "TR",
Expand Down Expand Up @@ -112,8 +113,9 @@ var respecConfig = {
href: "http://dcat.be/"
},
"DCAT-AP-IT": {
title: "Profilo nazionale dei metadati DCAT-AP_IT v1.0",
href: "https://www.dati.gov.it/content/profilo-nazionale-dei-metadati-dcat-ap-it-v10"
title: "Profilo metadatazione DCAT-AP_IT",
href: "https://docs.italia.it/italia/daf/linee-guida-cataloghi-dati-dcat-ap-it/it/stabile/dcat-ap_it.html",
publisher: "AgID & Team Digitale"
},
"DCAT-AP-NO": {
title: "Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO)",
Expand Down Expand Up @@ -194,6 +196,11 @@ var respecConfig = {
"title":"Named Authority List: Access rights",
"publisher":"Publications Office of the European Union"
},
"netCDF": {
href: "https://www.unidata.ucar.edu/software/netcdf/",
title: "Network Common Data Form (NetCDF)",
publisher: "UNIDATA"
},
"OBO" : {
href:"http://www.obofoundry.org/",
title:"The OBO Foundry"
Expand All @@ -207,12 +214,14 @@ var respecConfig = {
date:"29 July 2013",
publisher:"ODI"
},
/*
"OpenAPI": {
href: "https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md",
title: "OpenAPI Specification. Version 3.0.2",
date: "08 October 2018",
publisher: "OAI"
},
*/
"OpenSearch": {
authors: [
"DeWitt Clinton"
Expand Down Expand Up @@ -256,6 +265,13 @@ var respecConfig = {
href : "http://schema.org/",
title : "Schema.org"
},
"ShEx" : {
href : "http://shex.io/shex-semantics/",
title : "Shape Expressions Language 2.1",
date: "17 November 2018",
status: "Draft Community Group Report",
publisher: "Shape Expressions W3C Community Group"
},
"VIVO-ISF" : {
href:"http://github.com/vivo-isf/vivo-isf",
title:"VIVO-ISF Data Standard"
Expand All @@ -272,3 +288,4 @@ var respecConfig = {

}
};

Binary file modified dcat/images/ex-spatial-coverage-centroid-anne-frank-house.png
View file
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified dcat/images/ex-spatial-coverage-geometry-anne-frank-house.png
View file
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit be6eedd

Please sign in to comment.