Skip to content

Commit

Permalink
Merge branch 'gh-pages' into agb-issue-482
Browse files Browse the repository at this point in the history
  • Loading branch information
Simon Cox committed Mar 19, 2019
2 parents eb2e574 + 0a5f1ef commit 95d39bb
Show file tree
Hide file tree
Showing 12 changed files with 845 additions and 939 deletions.
9 changes: 9 additions & 0 deletions conneg-by-ap/config.js
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,15 @@ var respecConfig = {
issueBase: "https://github.com/w3c/dxwg/issues/",
github: "https://github.com/w3c/dxwg/",
localBiblio: {
"ARK" : {
editors: ["J. Kunze",
"R. Rodgers"
],
href: "https://tools.ietf.org/id/draft-kunze-ark-15.txt",
title: "The ARK Identifier Scheme" ,
date: "2008-05-22",
status: "Internet-Draft"
},
"PROF-CONNEG": {
editors: [
"Lars G. Svensson",
Expand Down
97 changes: 63 additions & 34 deletions conneg-by-ap/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -37,10 +37,13 @@ <h1>Introduction</h1>
<p>
Content delivered by dereferencing Internet identifiers can be negotiated for in different
ways. When using the HTTP protocol [[RFC7230]], a client may set one or more headers:
<ul><li>an <code>Accept</code> header specifying preferred Media Types which the server may or may not supply</li>
</p>
<ul>
<li>an <code>Accept</code> header specifying preferred Media Types which the server may or may not supply</li>
<li>an <code>Accept-Encoding</code> header to request that a specific content encoding system be used</li>
<li>an <code>Accept-Language</code> header to indicate a preferred language</li>
</ul>
</ul>
<p>
However, clients have not had a
defined way to negotiate for content based on its adherence to an information model - a standard, a specification or
a <a>profile</a> - and this document addresses this functionality.
Expand Down Expand Up @@ -166,7 +169,8 @@ <h2>Related Work</h2>
current version of the IETF draft (-00) is expected to be completely re-written in parallel work with this document and should
not be seen as anything but work-in-progress.
</p>
<h3>Existing standards for transporting profile information in HTTP headers</h3>
<section id="relatedwork-existingHttpStandards">
<h3>Existing standards for transporting profile information in HTTP headers</h3>
<h4>Using Accept/Content Type together with the profile parameter</h4>
<p>The HTTP Accept and Content-Type header fields [[RFC 7231]]
allow a client to specify acceptable media types (<code>Accept</code>)
Expand All @@ -181,15 +185,15 @@ <h4>Using Accept/Content Type together with the profile parameter</h4>
text/turtle;q=0.7;profile="urn:example:profile-2"

HTTP/1.1 200 OK
Content-Type: text/turtle;profile=<urn:example:profile-2>
Content-Type: text/turtle;profile="urn:example:profile-2"
</pre>
<p>During TPAC 2018 in Lyon, the DXWG had a longer discussion with the JSON-LD WG
and it was concluded that the “profile” parameter in the <code>Accept</code> and <code>Content-Type</code>
headers should be seen to convey profiles that are specific to the media-type,
such as the JSON-LD profiles "expanded" (<code>http://www.w3.org/ns/json-ld#expanded</code>) or
"flattened" (<code>http://www.w3.org/ns/json-ld#flattened</code>).
In order to signal the use of media-type-independent profiles,
the http header fields </code>Accept-Profile</code> and <code>Content-Profile</code> are to be used.</p>
the http header fields <code>Accept-Profile</code> and <code>Content-Profile</code> are to be used.</p>
<h4>Using a Link-header with rel=”profile” (RFC 6906)</h4>
<p>The HTTP Link header field [[RFC 8288]] relates a web resource (Link Context)
to a target resource (Link Target
Expand Down Expand Up @@ -224,11 +228,11 @@ <h4>Using the Prefer/Preference-Applied header fields (RFC 7240)</h4>
<pre class="example nohighlight" aria-busy="false" aria-live="polite" title="Using a Link header with a profile parameter">
GET /some/resource HTTP/1.1
Accept: text/turtle
Prefer: profile=&lt;urn:example:schema&gt;
Prefer: profile="urn:example:schema"

HTTP/1.1 200 OK
Content-Type: text/turtle
Preference-Applied: profile=&lt;urn:example:schema&gt;
Preference-Applied: profile="urn:example:schema"
</pre>
<p>This approach has two disadvantages.
The first is - as with the <code>Link</code> header,
Expand Down Expand Up @@ -259,10 +263,28 @@ <h4>Using the Prefer/Preference-Applied header fields (RFC 7240)</h4>
or other HTTP headers for this use
will be listed and discussed here.
</p>
</section>
<section id="relatedWork-ark">
<h3>Archival Resource Key (ark)</h3>
<p>ARK (Archival Resource Key) [[ARK]] is an identifier scheme
for the persistent identification of information objects.
ARK identifiers can contain an optional qualifier
"that extends the base ARK in order to create a kind of service entry point
into the object named by the NAA [sc. Name Assigning Authority]."
Through a qualifier, any NMA (Name Mapping Authority, service provider offering ARK resolution)
can supply access to variants of that object.
The set of qualifiers is open and any ARK NAA or NMA can invent its own.
The ARK specification lists versions, languages and formats as examples of qualifiers (§2.5)
and a profile name could be used as a qualifier
to refer to a representation of an information object conforming to that specific profile.
E. g. does <a href="https://api.istex.fr/ark:/67375/6GQ-MLC8GRWC-5/">https://api.istex.fr/ark:/67375/6GQ-MLC8GRWC-5/</a>
refer to different XML encodings of the metadata, one using MODS, the other one using other XML vocabularies.
</p>
</section>
<div class="issue" data-number="383"></div>
<div class="issue" data-number="516"></div>
<div class="issue" data-number="384"></div>
<div class="issue" data-number="514"></div>

</section>
<section id="abstractmodel">
<h2>Abstract Model</h2>
Expand Down Expand Up @@ -323,21 +345,9 @@ <h3>Requests and Responses</h3>
to a particular <em>profile</em>
</li>
</ol>
<p>
A third <em>request</em> type is given that is expected not to apply to all realizations of this abstract model
and not all clients adhering to this specification need implement it.
</p>
<ol start="3">
<li>
<strong>list profiles tokens</strong><br />
a <em>client</em> requests the list of <em>token</em>s that the <em>server</em> uses for <em>profile</em>s and for which the
<em>server</em> is able to deliver <em>resource</em> representations that conform to the profile. The server also provides a mapping from tokens to
<em>profile</em> URIs
</li>
</ol>
<p>
A <em>server</em> adhering to this specification MUST respond to each request with the following
<em>response</em>s. The first two types are required, handling the third depends on the realization environment.
<em>response</em>s.
</p>
<ol>
<li>
Expand All @@ -350,11 +360,6 @@ <h3>Requests and Responses</h3>
a <em>server</em> responds with either a specific <em>profile</em> for a <em>resource</em> conforming to a
requested <em>profile</em> identified by the <em>client</em> or it responds with a default <em>profile</em>
</li>
<li>
<strong>list profiles tokens</strong><br />
a <em>server</em> responds with the list of <em>profile </em> <em>token</em>s for which it is able to deliver
conformant <em>resource</em> representations and the mapping of the tokens to <em>profile</em> URIs.
</li>
</ol>
<div class="issue" data-number="587"></div>
<p>More detailed descriptions of these requests and their responses are given next.</p>
Expand All @@ -381,12 +386,6 @@ <h4>list profiles</h4>
it is unable to deliver those representations when presented with a <strong>get resource by profile</strong>
<em>request</em>.
</p>
<h5>Token listing</h5>
<p>
If, in addition to providing references to <em>profile</em>s via URI, a <em>server</em> wishes to provide
<em>token</em>s that map to URIs, it MUST provide a way of listing token/URI mappings to <em>client</em>s via the
<strong>list profiles</strong> request.
</p>
</section>
<section id="getresourcebyprofile">
<h4>get resource by profile</h4>
Expand Down Expand Up @@ -950,15 +949,45 @@ <h2>Implementations</h2>
</ul>
<div class="issue" data-number="467"></div>
</section>
<section id="acknowledgements" class="informative">
<h2>Acknowledgements</h2>
<p>Comments and suggestions from
Annette Greiner,
Erik Wilde,
Gregg Kellogg
and Kam Hay Fung
improved this specification
</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>
<li>Added text about existing standards for transporting profile information in http headers
to <a href="#relatedwork">related work</a>.
(<a href="https://github.com/w3c/dxwg/issues/45">Issue 45</a>)</li>
<li>Removed advice on use of HTTP OPTIONS.
(<a href="https://github.com/w3c/dxwg/issues/510">Issue 510</a>)</li>
<li>Added text about ARK identifiers to <a href="#relatedwork">related work</a>.
(<a href="https://github.com/w3c/dxwg/issues/514">Issue 514</a>)</li>
<li>Clarified difference between the <code>profile</code> parameter in <code>Accept</code> header fields
and the <code>Accept-Profile</code> header field.
(<a href="https://github.com/w3c/dxwg/issues/662">Issue 662</a>)</li>
<li>Updated the <a href="#security_and_privacy">Security and Privacy</a> section.
(<a href="https://github.com/w3c/dxwg/issues/782">Issue 782</a>)</li>
</ul>
</section>
<section id="security_and_privacy" class="informative">
<h2>Security and Privacy</h2>
<p>
The use of HTTP to negotiate and transport implies that all privacy and security issues
that are relevant for that protocol are also relevant for profile negotiation. E. g.,
information such as user agent, accept-headers, IP address etc. can potentially be used as
identifying information, and particularly, the IP address adds information about geolocation
and institutional membership. Apart from that, there are no known security or privacy impacts
of this feature.
and institutional membership.
Further, offering a list of acceptable profiles at the beginning of a negotiation process
can reveal information about the user's interests
that could be used to add such information to a user profile.
</p>
<p>
For a more complete view of those issues, cf. the
Expand Down
36 changes: 20 additions & 16 deletions dcat/config.js
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,10 +10,10 @@ var respecConfig = {
edDraftURI: "https://w3c.github.io/dxwg/dcat/",
// issueBase: "https://github.com/w3c/dxwg/issues/", -- Not needed when github used
editors: [{
name: "Alejandra Gonzalez Beltran",
company: "Oxford eResearch Centre, Engineering Science, University of Oxford",
url: "https://www.oerc.ox.ac.uk/people/alejandra",
companyURL: "http://www.oerc.ox.ac.uk/"
name: "Riccardo Albertoni",
company: "CNR - Consiglio Nazionale delle Ricerche, Italy",
url: "http://www.imati.cnr.it/joomla/index.php/people/8-curricula/178-riccardo-albertoni",
companyURL: "http://www.cnr.it/"
},{
name: "Dave Browning",
company: "Refinitiv",
Expand All @@ -23,24 +23,28 @@ var respecConfig = {
company: "CSIRO",
url: "http://people.csiro.au/Simon-Cox",
companyURL: "https://www.csiro.au/"
},{
name: "Alejandra Gonzalez Beltran",
company: "Oxford eResearch Centre, Engineering Science, University of Oxford",
url: "https://www.oerc.ox.ac.uk/people/alejandra",
companyURL: "http://www.oerc.ox.ac.uk/"
},{
name: "Andrea Perego",
company: "European Commission, Joint Research Centre (JRC)",
url: "https://joinup.ec.europa.eu/user/14209",
companyURL: "https://ec.europa.eu/jrc/"
},{
name: "Peter Winstanley",
company: "Scottish Government",
companyURL: "http://www.gov.scot/"
}],
otherLinks: [{
// key: "Contributors",
// data: [{
// value: "Makx Dekkers",
// href: "http://www.makxdekkers.com"
// },{
// value: "Antoine Isaac, Europeana Foundation",
// href: "https://pro.europeana.eu/person/antoine-isaac"
// },{
// value: "Andrea Perego, European Commission",
// href: "https://ec.europa.eu/jrc/"
// }]
// },{
key: "Contributors",
data: [{
value: "Makx Dekkers",
href: "http://www.makxdekkers.com"
}]
},{
key: "Editors of previous version",
data: [{
value: "Fadi Maali, DERI",
Expand Down
Loading

0 comments on commit 95d39bb

Please sign in to comment.