diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html
index f4f3396fd..68f3c865f 100644
--- a/conneg-by-ap/index.html
+++ b/conneg-by-ap/index.html
@@ -24,7 +24,7 @@ <h3>Overview of DXWG documents on profiles</h3>
         and the Internet Engineering Taskforce (IETF). The documents are:
       </p>
       <ul>
-        <li>[[PROF]] - the <em>Profiles Vocabulary</em>: an RDF vocabulary that describes profiles and related resources</li>
+        <li>[[?PROF]] - the <em>Profiles Vocabulary</em>: 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]] - <em>Indicating and Negotiating Profiles in HTTP</em>: 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>The DXWG also plans to provide [[PROF-GUIDANCE]] - <em>Profile Guidance</em>: general recommendations and guidance on profiling.</li>
@@ -55,7 +55,7 @@ <h2>Introduction</h2>
       For example, a catalog may offer choices of representations of a dataset's description that conform to different information models, perhaps [[VOID]],
       [[VOCAB-DATA-CUBE]] and [[VOCAB-DCAT]]. Furthermore, the [[VOCAB-DCAT]] representation might conform to the
       [[DCAT-AP]] profile, the [[GeoDCAT-AP]] profile and perhaps also an organisation-specific profile "MyOrgDCATProfile".
-      These "narrower" profiles constrains various elements of the dataset's description above and beyond the "broader", more general, specification or profile that they profile.
+      These "narrower" profiles constrain various elements of the dataset's description above and beyond the "broader", more general, specification or profile that they profile.
       A request for information about this dataset description's possible representations may
       ask for the list of profiles to which conformant representations of it are available, or may ask specifically for a representation conforming to one profile, for example
       [[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default content,
@@ -93,7 +93,7 @@ <h2>Introduction</h2>
     <p>
       Describing how resources' representations conform to profiles and how profiles and specifications relate to one
       another is not part of this specification. Parts of those questions are addressed by the Profiles Vocabulary
-      [[PROF]], also produced by the DXWG.
+      [[?PROF]], also produced by the DXWG.
     </p>
   </section>
   <section id="conformance">
@@ -208,7 +208,7 @@ <h2>Motivation</h2>
       This document describes an abstract, functions-based, specification for content negotiation by profile and gives both an
       HTTP functional profile and two Query String Argument-based functional profiles for the specification's implementation in different environments. The query string
 	   approaches provide both a "fall back" (second, non-HTTP implementation of the abstract specification), as required by the
-      <a href="https://www.w3.org/2017/dxwg/charter">Dataset Exchange Working Group's Charter</a> (Section 2.3) and also demonstrations functional profiles of the abstract specification that potential functional profile implementers may take as guidance for their implementations.
+      <a href="https://www.w3.org/2017/dxwg/charter">Dataset Exchange Working Group's Charter</a> (Section 2.3) and also demonstrates functional profiles of the abstract specification that potential functional profile implementers may take as guidance for their implementations.
     </p>
     <p>
       Other query string or REST-based functional profiles and indeed radically different environment's implementation of this abstract specification
@@ -374,7 +374,7 @@ <h3>OAI-PMH</h3>
       </p>
       <p>
         OAI-PMH requires that representations of all resources in a repository are available according to the same set
-        of profiles (what it calls <em>formats</em>). It is also entirely XML-based so that profiles, must
+        of profiles (what it calls <em>formats</em>). It is also entirely XML-based so that profiles must
         all be presented in XML and the content of an XML representation of a resource is presented within an XML
         envelope that always identifies the record, the profile, the OAI-PMH method used, the request time and other
         common metadata.
@@ -449,7 +449,7 @@ <h3>Profile Identification</h3>
       </p>
       <p>
         If a URI is used for profile identification, it SHOULD be an HTTP
-        URI that dereferences to a description of the profile. Other kinds or URIs, e. g. URNs MAY also be used and these may no be capable of dereferencing.
+        URI that dereferences to a description of the profile. Other kinds or URIs, e. g. URNs MAY also be used and these may not be capable of dereferencing.
         If a token is used, it MUST unambiguously identify the
         <a>profile</a> within a <a>request</a>/<a>response</a> pair of messages.
         The server MUST declare the context within which the token may be mapped to a URI.
@@ -469,7 +469,7 @@ <h3>Requests and Responses</h3>
         </li>
         <li>
           <strong>get resource by profile</strong>
-          <br />a <a>client</a> requests a <a>representation</a> of the requested <a>resource</a> represented conforming
+          <br />a <a>client</a> requests a <a>representation</a> of the requested <a>resource</a> conforming
           to a particular <a>profile</a>
         </li>
       </ol>
@@ -694,7 +694,7 @@ <h4>get resource by profile</h4>
           For example, a response from a server that conforms to both [[?GeoDCAT-AP]] and also [[?STATDCAT-AP]], given
           that neither profiles the other and thus no single indication of conformance will suffice for both, (note they
           both do profile [[?DCAT-AP]], see the <a href="https://www.w3.org/TR/dx-prof/#eg-hierarchy">DCAT-AP Hierarchy
-          example in [[PROF]]</a>), using profile URIs for [[?GeoDCAT-AP]] and [[?STATDCAT-AP]] could be:
+          example in [[?PROF]]</a>), using profile URIs for [[?GeoDCAT-AP]] and [[?STATDCAT-AP]] could be:
         </p>
         <p>
           <code>Content-Profile: &lt;https://joinup.ec.europa.eu/release/geodcat-ap-v10>, &lt;https://joinup.ec.europa.eu/release/statdcat-ap/101></code>
@@ -843,7 +843,7 @@ <h3>Conformance to Functional Profiles</h3>
     <section id="http">
       <h3>Hypertext Transfer Protocol Headers</h3>
       <p>
-        An functional profile of the Abstract Model using Hypertext Transfer Protocol (HTTP) headers is presented here.
+        A functional profile of the Abstract Model using Hypertext Transfer Protocol (HTTP) headers is presented here.
         This implementation is based on HTTP content negotiation and uses <code>Link</code> headers formulated in
         particular ways and two new HTTP headers,
 	      <code>Accept-Profile</code> and <code>Content-Profile</code> that are to be defined in an upcoming
@@ -1912,12 +1912,12 @@ <h3>Profiles of this specification</h3>
       <p>
         This specification contains a number of distinct <a>functional profiles</a> that are identified and described in words in
         <a href="#conformance-profiles"></a>. This appendix presents descriptions of these functional profiles, and the relations
-        between them, according to the Profiles Vocabulary [[PROF]].
+        between them, according to the Profiles Vocabulary [[?PROF]].
       </p>
       <p>
         The RDF (turtle syntax) code in <a href="#profiles-in-prof">Code Listing 1</a> defines <em>Content Negotiation
         by Profile</em> as a <code><a href="http://purl.org/dc/terms/Standard">dct:Standard</a></code>, the definition
-        of which in [[PROF]] matches the definition of <a>specification</a> in this document. The 4 profiles of it are
+        of which in [[?PROF]] matches the definition of <a>specification</a> in this document. The 4 profiles of it are
         then, as per regular PROF modelling, termed <code><a href="https://www.w3.org/TR/dx-prof/#Class:Profile">
         prof:Profiles</a></code>. The 4 profiles are presented in a hierarchy with the profiles either directly
         profiling the standard or, in the case of the <em>QSA Realization</em> profile, profiling another profile that then
@@ -1932,7 +1932,7 @@ <h3>Profiles of this specification</h3>
         Functional Profile</em> profile is that the <em>QSA Functional Profile</em> profile is a more constrained 'narrower'
         specification of <em>Content Negotiation by Profile</em> than <em>QSA Alternate Keywords Functional Profile</em> and
         anything that is conformant with the <em>QSA Functional Profile</em> profile would necessarily by conformant with the
-        <em>QSA Alternate Keywords Functional Profile</em> profile which thus meets the [[PROF]] definition of what it means
+        <em>QSA Alternate Keywords Functional Profile</em> profile which thus meets the [[?PROF]] definition of what it means
         to be the profile of something.
       </p>
       <pre id="profiles-in-prof"
@@ -2003,9 +2003,9 @@ <h3>Profiles of this specification</h3>
         <h4>Demonstrating conformance to profiles</h4>
         <p>
           With the identification of profiles of this specification given in <a href="#conformance-profiles"></a> and
-          their relations described using the Profiles Vocabulary [[PROF]] in this appendix, it is possible for
+          their relations described using the Profiles Vocabulary [[?PROF]] in this appendix, it is possible for
           resources to show conformance to the this specification or any of the profiles by using mechanisms recommended
-          in [[PROF]]. PROF's recommendation is that any resource, for example <code>&lt;http://example.org/resource/a&gt;</code>,
+          in [[?PROF]]. PROF's recommendation is that any resource, for example <code>&lt;http://example.org/resource/a&gt;</code>,
           wishing to claim conformance to a <a>specification</a> or a <a>profile</a> use the [[DCTERMS]]
           <code><a href="http://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-conformsTo">
             dct:conformsTo</a></code> predicate like this:
@@ -2022,7 +2022,7 @@ <h4>Demonstrating conformance to profiles</h4>
           The code in <a href="#service-conforming">Code Listing 2</a> shows an imaginary Web Service documented using
           [[?VOCAB-DCAT-2]] and borrowing parts from its examples, such as
           <a href="https://www.w3.org/TR/vocab-dcat-2/#ex-service-eea">Example 49</a>,
-          that includes a <code>dct:conformsTo</code> predicate as [[?VOCAB-DCAT-2]], as well as [[PROF]], suggest for
+          that includes a <code>dct:conformsTo</code> predicate as [[?VOCAB-DCAT-2]], as well as [[?PROF]], suggest for
           use. Conformance here is claimed to be to the <em>QSA Alternate Keywords Functional Profile</em> profile indicated by
           the URI <code>http://www.w3.org/ns/dx/conneg/profile/qsa-alt</code>, as it is identified in
           <a href="#conformance-profiles"></a>.