From f745a1415caacb2d952143680cd12a57644b4fd4 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Tue, 16 Apr 2019 22:20:30 +1000 Subject: [PATCH 01/26] ORCIDs --- profilesont/config.js | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/profilesont/config.js b/profilesont/config.js index 9f778873e..afb84d5e7 100644 --- a/profilesont/config.js +++ b/profilesont/config.js @@ -9,13 +9,15 @@ var respecConfig = { { name: "Rob Atkinson", company: "Metalinkage, Open Geospatial Consortium", - companyURL: "http://www.opengeospatial.org/" + companyURL: "http://www.opengeospatial.org/", + orcid: "0000-0002-7878-2693" }, { name: "Nicholas J. Car", url: "https://people.csiro.au/Nicholas-Car", company: "CSIRO", companyURL: "https://www.csiro.au/", + orcid: "0000-0002-8742-7730", w3cid: 70131 }], otherLinks: [{ From 6fc1d2925c16102d8ffa9442c3e83e33a94b322d Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Wed, 24 Apr 2019 07:20:54 +1000 Subject: [PATCH 02/26] added Acknowledgements --- profilesont/index.html | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/profilesont/index.html b/profilesont/index.html index d89471b60..692a24e9a 100644 --- a/profilesont/index.html +++ b/profilesont/index.html @@ -1591,6 +1591,23 @@

Changes

Appendices

+
+

Acknowledgements

+

+ The editors acknowledge the chairs of this Working Group: Karen Coyle & Peter Winstanley and the staff + contact Dave Raggett. +

+

+ The editors also gratefully acknowledge the contributions made to this document by all members of the Dataset + Exchange Working Group, specially the contributions received from Karen Coyle, Antoine Isaac, Andrea Perego and + Tom Baker. +

+

+ The editors would also like to thank non-members of this working group for their comments, changes and ideas from + which have been incorporated into this document. In particular: Paul Walk, Leslie Sikos, Stephen Richard, + Kam Hay Fung, Heidi Vanparys and Irene Polikoff. +

+
From 0cc67c39b3adfbe210d1cf12e75f8268bbe3d0d0 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 15 Jul 2019 16:05:29 +1000 Subject: [PATCH 03/26] first attempt --- conneg-by-ap/index.html | 75 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index cb307f021..d97395eeb 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -85,6 +85,81 @@

Introduction

Section 8.

NB Profiles and specifications embody their own notions of conformance (of data), which are out of scope for this document.

+
+

Profiles for Conformance

+

+ This specification includes several profiles of it that may be conformed to by systems claiming to implement a form of this specification. + These profiles, given in the table below, are identified by their URIs and conformance to them by Internet resources should be indicated as per this document (use of + Content-Profile HTTP header). +

+

+ The namespace prefix for these profiles used in is: +

+
    +
  • pp → http://www.w3.org/ns/dx/prof/profile/
    • +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
URINameDescriptionUsage Note
pp:abstractAbstract ModelFor conformance with the model presented in .Not to be used if a resource also conforms to a more concrete profile (all of the others)
pp:httpHTTP RealizationFor conformance with the realization presented in .To be used if a resource conforms to the HTTP Realization
pp:qsa-strictQSA Realization (strict)For conformance with the realization presented in . + To be used if a resource conforms to the strict form of the QSA Realization where the Query String Arguments _profile and _mediatype + are used as per the recommendations in . +
pp:qsa-looseQSA Realization (loose)For conformance with the realization presented in . + To be used if a resource conforms to the loose form of the QSA Realization where the Query String Arguments may differ from _profile and + _mediatype. Should not be used if the conforming implementation adheres to the QSA (strict) profile. +
+
+ Profiles of this Content Negotiation by Profile specification to be used by resources and systems to indicate conformance to one or more forms + of it. +
+
+

+ The namespace used for the above profiles, http://www.w3.org/ns/dx/prof/profile/, is part of the Profiles Vocabulary [[PROF]]'s namespace and is used for + these instances of PROF's prof:Profile class just as instances of PROF's prof:Role class use http://www.w3.org/ns/dx/prof/role/ + (see [[PROF]]). +

+

+ If a system wishes to show conformance to this specification, conformance to at least one of the profiles listed in MUST be indicated. +

+
+ Another sentense/paragraph is needed here to indicate what shows conformance. It's not /resource/a's representation but something else as /resource/a + may conform to some (data) profile but that data profile has nothing to do with CONNEG. It's the systems mechanics that are conformant here, unless we have a required + resource that all implementations of this must implement that can describe the system function that conforms to the above. +
+

Definitions

From 21ee6d3de2ca04f23e15acda5970df795b52905f Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Fri, 19 Jul 2019 07:54:52 +1000 Subject: [PATCH 04/26] renamed QSA profiles, change to /dx/conneg namespace, added 5th profile --- conneg-by-ap/index.html | 39 ++++++++++++++++++++++++--------------- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index d97395eeb..7b874d7a7 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -96,7 +96,7 @@

Profiles for Conformance

The namespace prefix for these profiles used in is:

    -
  • pp → http://www.w3.org/ns/dx/prof/profile/
    • +
  • pc → http://www.w3.org/ns/dx/conneg/profile/
@@ -110,33 +110,42 @@

Profiles for Conformance

- + - + - - + + - - + + + + + + + + @@ -147,15 +156,15 @@

Profiles for Conformance

- The namespace used for the above profiles, http://www.w3.org/ns/dx/prof/profile/, is part of the Profiles Vocabulary [[PROF]]'s namespace and is used for - these instances of PROF's prof:Profile class just as instances of PROF's prof:Role class use http://www.w3.org/ns/dx/prof/role/ - (see [[PROF]]). + The namespace used for the above profiles, http://www.w3.org/ns/dx/conneg/profile/, is part of the Dataset Exchange Working Group's reserved W3C namespace, + http://www.w3.org/ns/dx/, which is provisioned for all namespace requirements to do with issues addressed by that Working Group. The /profile/ path segment + indicates a register of profile objects which currently contains just the 5 instances above from .

If a system wishes to show conformance to this specification, conformance to at least one of the profiles listed in MUST be indicated.

- Another sentense/paragraph is needed here to indicate what shows conformance. It's not /resource/a's representation but something else as /resource/a + Another sentense/paragraph is needed here to indicate what shows conformance. It's not /a/resource's representation but something else as /a/resource may conform to some (data) profile but that data profile has nothing to do with CONNEG. It's the systems mechanics that are conformant here, unless we have a required resource that all implementations of this must implement that can describe the system function that conforms to the above.
From 2f9a89b306c2cd42615c5a4d7d9d06eb263387ab Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Fri, 19 Jul 2019 12:45:14 +1000 Subject: [PATCH 05/26] start of profiles in PROF appendix --- conneg-by-ap/index.html | 76 +++++++++++++++++++++++++++--- conneg-by-ap/profile-hierarchy.svg | 1 + 2 files changed, 71 insertions(+), 6 deletions(-) create mode 100644 conneg-by-ap/profile-hierarchy.svg diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 7b874d7a7..c2f8dbef8 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -85,10 +85,10 @@

Introduction

Section 8.

NB Profiles and specifications embody their own notions of conformance (of data), which are out of scope for this document.

-
+

Profiles for Conformance

- This specification includes several profiles of it that may be conformed to by systems claiming to implement a form of this specification. + This specification includes several profiles of it that may be conformed to by systems claiming to implement a form of this specification. These profiles, given in the table below, are identified by their URIs and conformance to them by Internet resources should be indicated as per this document (use of Content-Profile HTTP header).

@@ -116,13 +116,13 @@

Profiles for Conformance

 - + - + - - + + - +
pp:abstractcp:abstract Abstract Model For conformance with the model presented in . Not to be used if a resource also conforms to a more concrete profile (all of the others)
pp:httpcp:http HTTP Realization For conformance with the realization presented in . To be used if a resource conforms to the HTTP Realization
pp:qsa-strictQSA Realization (strict)cp:qsaQSA Realization For conformance with the realization presented in . - To be used if a resource conforms to the strict form of the QSA Realization where the Query String Arguments _profile and _mediatype - are used as per the recommendations in . + To be used if a resource conforms to the QSA Realization using the Query String Arguments _profile and _mediatype as per the recommendations + in .
pp:qsa-looseQSA Realization (loose)cp:qsa-altQSA Realization (alternate keywords) For conformance with the realization presented in . - To be used if a resource conforms to the loose form of the QSA Realization where the Query String Arguments may differ from _profile and - _mediatype. Should not be used if the conforming implementation adheres to the QSA (strict) profile. + To be used if a resource conforms to the QSA Realization but uses alternate keywords for the Query String Arguments _profile and + _mediatype, as allowed by the recommendations in . +
cp:rrdResource Representation DescriptionFor conformance with . + To be used if a resource representation is able to indicate which profile(s) it conforms to, in its appropriate realization, as per the abstract specification in + .
Not to be used if a resource also conforms to a more concrete profile (all of the others)
cp:httpcp:http HTTP Realization For conformance with the realization presented in . To be used if a resource conforms to the HTTP Realization
cp:qsacp:qsa QSA Realization For conformance with the realization presented in . @@ -131,8 +131,8 @@

Profiles for Conformance
cp:qsa-altQSA Realization (alternate keywords)cp:qsa-altQSA Alternate Keywords Realization For conformance with the realization presented in . To be used if a resource conforms to the QSA Realization but uses alternate keywords for the Query String Arguments _profile and @@ -155,6 +155,9 @@

Profiles for Conformance

of it. +

+ Non-normative, formal, descriptions of the profiles in are given in . +

The namespace used for the above profiles, http://www.w3.org/ns/dx/conneg/profile/, is part of the Dataset Exchange Working Group's reserved W3C namespace, http://www.w3.org/ns/dx/, which is provisioned for all namespace requirements to do with issues addressed by that Working Group. The /profile/ path segment @@ -1040,6 +1043,67 @@

Security and Privacy

Appendices

+
+

Profiles of this specification

+

+ This specification contains a number of distinct profiles that are identified and described in words in . This appendix presents descriptions of + these profiles, and the relations between them, according to the Profiles Vocabulary [[PROF]]. +

+ 
+@prefix dct: <http://purl.org/dc/terms/> .
+@prefix prof: <http://www.w3.org/ns/dx/prof/> .
+@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+
+<https://www.w3.org/TR/dx-prof-conneg/> a dct:Standard ;
+    rdfs:label "Content Negotiation by Profile" .
+
+<http://www.w3.org/ns/dx/conneg/profile/abstract> a prof:Profile ;
+    prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ;
+    rdfs:label "Abstract Model profile of Content Negotiation by Profile" .
+
+<http://www.w3.org/ns/dx/conneg/profile/http> a prof:Profile ;
+    prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ;
+    rdfs:label "HTTP Realization profile of Content Negotiation by Profile" .
+
+<http://www.w3.org/ns/dx/conneg/profile/qsa> a prof:Profile ;
+    prof:isProfileOf <http://www.w3.org/ns/dx/conneg/profile/abstract> ;
+    rdfs:label "QSA Realization profile of Content Negotiation by Profile" .
+
+<http://www.w3.org/ns/dx/conneg/profile/qsa-alt> a prof:Profile ;
+    prof:isProfileOf <http://www.w3.org/ns/dx/conneg/profile/abstract> ;
+    rdfs:label "QSA Alternate Keywords Realization profile of Content Negotiation by Profile" .
+
+<http://www.w3.org/ns/dx/conneg/profile/rrd> a prof:Profile ;
+    prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ;
+    rdfs:label "Resource Representation Description profile of Content Negotiation by Profile" .
+
+

+ The code listing describes this Content Negotiation by Profile specification as a + dct:Standard and the 5 profiles of it in a profile hierarchy with the Abstract Model and Resource Representation Description + profiles profiling the specification directly and the other four profiles profiling the Abstract Model profile. This is shown graphically in below. +

+
+ Profile hierarchy of this specification +
+ The specification and profiles of this Content Negotiation by Profile standard shown in a [[PROF] profiles hierarchy. +
+
+
+

Demonstrating conformance to profiles

+

+ With the identification of profiles of this specification given in and their description of them using the Profiles Vocabulary [[PROF]] in this + appendix, it is possible for XXX to show conformance to one of more of these profiles as per +

+ 
+@prefix dct: <http://purl.org/dc/terms/> .
+
+<XXXX> dct:conformsTo <http://www.w3.org/ns/dx/conneg/profile/abstract> .
+
+

+ The information in can be used to... +

+

Requirements

diff --git a/conneg-by-ap/profile-hierarchy.svg b/conneg-by-ap/profile-hierarchy.svg new file mode 100644 index 000000000..eabe9de14 --- /dev/null +++ b/conneg-by-ap/profile-hierarchy.svg @@ -0,0 +1 @@ + \ No newline at end of file From 34605e5b6ed7d32fa52323e832f62b1423ef6378 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Fri, 19 Jul 2019 21:52:57 +1000 Subject: [PATCH 06/26] improvements in profiles of Conneg-by-P --- conneg-by-ap/index.html | 48 +++++++++++++++++++++++++---------------- 1 file changed, 29 insertions(+), 19 deletions(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index c2f8dbef8..6d7d921ee 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -96,7 +96,7 @@

Profiles for Conformance

The namespace prefix for these profiles used in is:

    -
  • pc → http://www.w3.org/ns/dx/conneg/profile/
    • +
  • cnpr → http://www.w3.org/ns/dx/conneg/profile/
@@ -110,19 +110,19 @@

Profiles for Conformance

- + - + - + - + @@ -1133,7 +1133,7 @@

Property: update/modification date

@@ -1570,7 +1570,7 @@

Property: listing date

@@ -1585,7 +1585,7 @@

Property: update/modification date

@@ -1984,7 +1984,7 @@

Property: release date

From c08bd310a0d80d6f99c6de5cdadb3f81f165b196 Mon Sep 17 00:00:00 2001 From: David Browning <33936348+davebrowning@users.noreply.github.com> Date: Wed, 24 Jul 2019 13:24:31 +0200 Subject: [PATCH 09/26] Add more --- dcat/index.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/dcat/index.html b/dcat/index.html index 308263f56..417bb0148 100644 --- a/dcat/index.html +++ b/dcat/index.html @@ -1118,7 +1118,7 @@

Property: release date

@@ -1570,7 +1570,7 @@

Property: listing date

@@ -1585,7 +1585,7 @@

Property: update/modification date

@@ -1984,7 +1984,7 @@

Property: release date

@@ -1999,7 +1999,7 @@

Property: update/modification date

+ encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime).
cp:abstractcnpr:abstract Abstract Model For conformance with the model presented in . Not to be used if a resource also conforms to a more concrete profile (all of the others)
cp:httpcnpr:http HTTP Realization For conformance with the realization presented in . To be used if a resource conforms to the HTTP Realization
cp:qsacnpr:qsa QSA Realization For conformance with the realization presented in . @@ -131,7 +131,7 @@

Profiles for Conformance
cp:qsa-altcnpr:qsa-alt QSA Alternate Keywords Realization For conformance with the realization presented in . @@ -1054,29 +1054,36 @@

Profiles of this specification

@prefix prof: <http://www.w3.org/ns/dx/prof/> . @prefix role: <http://www.w3.org/ns/dx/prof/role/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . +@prefix cnpr: <http://www.w3.org/ns/dx/conneg/profile/> . <https://www.w3.org/TR/dx-prof-conneg/> a dct:Standard ; - rdfs:label "Content Negotiation by Profile" . + rdfs:label "Content Negotiation by Profile" ; + rdfs:comment "The W3C Recommendation (a standard) for Content Negotiation by Profile" . -<http://www.w3.org/ns/dx/conneg/profile/abstract> a prof:Profile ; +cnpr:abstract a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ; - rdfs:label "Abstract Model profile of Content Negotiation by Profile" . + rdfs:label "Abstract Model Profile" ; + rdfs:comment "Abstract Model profile of Content Negotiation by Profile" . -<http://www.w3.org/ns/dx/conneg/profile/http> a prof:Profile ; +cnpr:http a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ; - rdfs:label "HTTP Realization profile of Content Negotiation by Profile" . + rdfs:label "HTTP Realization Profile" ; + rdfs:comment "HTTP Realization profile of Content Negotiation by Profile" . -<http://www.w3.org/ns/dx/conneg/profile/qsa> a prof:Profile ; +cnpr:qsa a prof:Profile ; prof:isProfileOf <http://www.w3.org/ns/dx/conneg/profile/abstract> ; - rdfs:label "QSA Realization profile of Content Negotiation by Profile" . + rdfs:label "QSA Realization Profile" ; + rdfs:comment "QSA Realization profile of Content Negotiation by Profile" . -<http://www.w3.org/ns/dx/conneg/profile/qsa-alt> a prof:Profile ; +cnpr:qsa-alt a prof:Profile ; prof:isProfileOf <http://www.w3.org/ns/dx/conneg/profile/abstract> ; - rdfs:label "QSA Alternate Keywords Realization profile of Content Negotiation by Profile" . + rdfs:label "QSA Alternate Keywords Realization Profile" ; + rdfs:comment "Query String Argument Alternate Keywords Realization profile of Content Negotiation by Profile" . -<http://www.w3.org/ns/dx/conneg/profile/rrd> a prof:Profile ; +cnpr:rrd a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ; - rdfs:label "Resource Representation Description profile of Content Negotiation by Profile" . + rdfs:label "Resource Representation Description Profile" ; + rdfs:comment "Resource Representation Description profile of Content Negotiation by Profile" .

The code listing describes this Content Negotiation by Profile specification as a @@ -1093,12 +1100,15 @@

Profiles of this specification

Demonstrating conformance to profiles

With the identification of profiles of this specification given in and their description of them using the Profiles Vocabulary [[PROF]] in this - appendix, it is possible for XXX to show conformance to one of more of these profiles as per + appendix, it is possible for services that deliver content according to the specification or any of the profiles to show conformance to the specification or any of the profiles by + using the same mechanisms recommended in [[PROF]] for a data resource to show conformance to a profile. For data resources, the recommendation is that they declare an RDF statement + such as </a/resource> dct:conformsTo <SPEC_OR_PROFILE_URI> .. This, adapted for use with services, is shown in .

- 
+        
 @prefix dct: <http://purl.org/dc/terms/> .
+@prefix cnpr: <http://www.w3.org/ns/dx/conneg/profile/> .
 
-<XXXX> dct:conformsTo <http://www.w3.org/ns/dx/conneg/profile/abstract> .
+<XXXX> dct:conformsTo cnpr:qsa-alt .
       

       

         The information in  can be used to...

From afe2c062f83a677cd50e2f70d4c521df723a1b4e Mon Sep 17 00:00:00 2001
From: Nicholas Car 
Date: Wed, 24 Jul 2019 08:44:24 +1000
Subject: [PATCH 07/26] data specification & data profile definitions updated

---
 conneg-by-ap/index.html | 34 ++++++++++++++++------------------
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html
index cb307f021..7056a1f34 100644
--- a/conneg-by-ap/index.html
+++ b/conneg-by-ap/index.html
@@ -89,34 +89,32 @@ 
Introduction

   

     
Definitions

     

-      
specification

+      
data specification

       

         

-          An act of identifying something precisely or of stating a precise requirement. - Oxford English Dictionary
+          A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.
         

         

-          One form of a specification is a standard which is a "basis for comparison; a reference
-          point against which other things can be evaluated" - [[DCTERMS]]
+          This document refers to both "data specifications" and also the more general "specifications". When the latter general case is referenced, its definition is taken
+          to be that of the DCMI Metadata Terms [[DCTERMS]]'s definition for a Standard, which is "A basis for comparison; a reference point against which other things
+          can be evaluated."
         

+        
Source: deliberations of the DXWG.

       

-      
profile

+      
data profile

       

         

-          A named set of constraints on one or more identified base specifications,
-          including the identification of any implementing subclasses of datatypes,
-          semantic interpretations, vocabularies, options and parameters of those base specifications
-          necessary to accomplish a particular function.
+          A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.
         

         

-          This definition includes what are often called "application profiles", "metadata application
-          profiles", or "metadata profiles".
+          This definition includes what are sometimes called "application profiles", "metadata application
+          profiles", or "metadata profiles". In this document, these, and "data profiles", are just referred to as just "profiles".
         

-        
Source: deliberations of the DXWG. See ProfileContext wiki page.

+        
Source: deliberations of the DXWG.

       

       
client

       

-        A program that establishes a connection to a server for the purpose of sending one or more HTTP requests
-        [[RFC7230]]
+        A program that establishes a connection to a server for the purpose of sending one or more HTTP requests. [[RFC7230]]
       

       
server

       

@@ -128,13 +126,13 @@ 
Definitions

         document, an image, a source of information with a consistent purpose. [[RFC3986]]
       

       
metadata

-      
Information that is supplied about a resource [[RFC3986]]

+      
Information that is supplied about a resource. [[RFC3986]]

       
request

-      
A message sent over the Internet, from a client to a server, for a information about a resource [[RFC7230]]

+      
A message sent over the Internet, from a client to a server, for a information about a resource. [[RFC7230]]

       
response

-      
A message sent over the Internet, from a server to a client answering a request for information about a resource [[RFC7230]]

+      
A message sent over the Internet, from a server to a client answering a request for information about a resource. [[RFC7230]]

       
token

-      
A short name identifying something, in the context of this document a profile

+      
A short name identifying something, in the context of this document, a profile.

     

   

   


From 6058e8484789fd226b223de801adb51cb365a834 Mon Sep 17 00:00:00 2001
From: David Browning <33936348+davebrowning@users.noreply.github.com>
Date: Wed, 24 Jul 2019 13:16:36 +0200
Subject: [PATCH 08/26] data/time clarification..

...to balance most appropriate use for interoperability as per #957
---
 dcat/index.html | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/dcat/index.html b/dcat/index.html
index 75aea7b71..308263f56 100644
--- a/dcat/index.html
+++ b/dcat/index.html
@@ -1118,7 +1118,7 @@ 
Property: release date
Definition:Date of formal issuance (e.g., publication) of the item.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime)
Usage note:This property SHOULD be set using the first known date of issuance.
See also: and
Definition:Most recent date on which the item was changed, updated or modified.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime)
Usage note:The value of this property indicates a change to the actual item, not a change to the catalog record. An absent value MAY indicate that the item has never changed after its initial publication, or that the date of last modification is not known, or that the item is continuously updated.
See also:, and
Definition:The date of listing (i.e. formal recording) of the corresponding dataset or service in the catalog.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime)
Usage note:This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself.
See also:
Definition:Most recent date on which the catalog entry was changed, updated or modified.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime)
Usage note:This indicates the date of last change of a catalog entry, i.e. the catalog metadata description of the dataset, and not the date of the dataset itself.
See also:
Definition:Date of formal issuance (e.g., publication) of the distribution.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime)
Usage note:This property SHOULD be set using the first known date of issuance.
See also:
Definition:Date of formal issuance (e.g., publication) of the item.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime) + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]](xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime).
Usage note:This property SHOULD be set using the first known date of issuance.
See also: and
Definition:The date of listing (i.e. formal recording) of the corresponding dataset or service in the catalog.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime) + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime).
Usage note:This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself.
See also:
Definition:Most recent date on which the catalog entry was changed, updated or modified.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime) + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime).
Usage note:This indicates the date of last change of a catalog entry, i.e. the catalog metadata description of the dataset, and not the date of the dataset itself.
See also:
Definition:Date of formal issuance (e.g., publication) of the distribution.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime) + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime).
Usage note:This property SHOULD be set using the first known date of issuance.
See also:
Definition:Most recent date on which the distribution was changed, updated or modified.
Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
See also:
@@ -2747,7 +2747,7 @@

Property: start date
Definition:The start of the period.
Domain:dct:PeriodOfTime
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime).
From 25c603f9b62787cbf4ec1c697f7cc71a953a422c Mon Sep 17 00:00:00 2001 From: David Browning <33936348+davebrowning@users.noreply.github.com> Date: Wed, 24 Jul 2019 13:35:42 +0200 Subject: [PATCH 10/26] Typos --- dcat/index.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/dcat/index.html b/dcat/index.html index 417bb0148..419e8e34f 100644 --- a/dcat/index.html +++ b/dcat/index.html @@ -1118,7 +1118,7 @@

Property: release date

Definition:Date of formal issuance (e.g., publication) of the item. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]](xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]](xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This property SHOULD be set using the first known date of issuance. See also: and @@ -1133,7 +1133,7 @@

Property: update/modification date

Definition:Most recent date on which the item was changed, updated or modified. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime) + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime) Usage note:The value of this property indicates a change to the actual item, not a change to the catalog record. An absent value MAY indicate that the item has never changed after its initial publication, or that the date of last modification is not known, or that the item is continuously updated. See also:, and @@ -1570,7 +1570,7 @@

Property: listing date

Definition:The date of listing (i.e. formal recording) of the corresponding dataset or service in the catalog. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself. See also: @@ -1585,7 +1585,7 @@

Property: update/modification date

Definition:Most recent date on which the catalog entry was changed, updated or modified. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This indicates the date of last change of a catalog entry, i.e. the catalog metadata description of the dataset, and not the date of the dataset itself. See also: @@ -1984,7 +1984,7 @@

Property: release date

Definition:Date of formal issuance (e.g., publication) of the distribution. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This property SHOULD be set using the first known date of issuance. See also: @@ -1999,7 +1999,7 @@

Property: update/modification date

Definition:Most recent date on which the distribution was changed, updated or modified. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). See also: @@ -2747,7 +2747,7 @@

Property: start date

Definition:The start of the period. Domain:dct:PeriodOfTime - Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsg:gYearMonth, xsd:date, or xsd:dateTime). + Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). From a6afc588f212e0d4183b2f0f644e18c90e181fe5 Mon Sep 17 00:00:00 2001 From: David Browning <33936348+davebrowning@users.noreply.github.com> Date: Wed, 24 Jul 2019 13:50:53 +0200 Subject: [PATCH 11/26] Link (test) --- dcat/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dcat/index.html b/dcat/index.html index 419e8e34f..a03822ad7 100644 --- a/dcat/index.html +++ b/dcat/index.html @@ -1118,7 +1118,7 @@

Property: release date

Definition:Date of formal issuance (e.g., publication) of the item. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]](xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This property SHOULD be set using the first known date of issuance. See also: and From cc71f95fcd31583ca4267ab2cfb45532d8fabc0d Mon Sep 17 00:00:00 2001 From: David Browning <33936348+davebrowning@users.noreply.github.com> Date: Wed, 24 Jul 2019 13:55:36 +0200 Subject: [PATCH 12/26] Remaining refs --- dcat/index.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/dcat/index.html b/dcat/index.html index a03822ad7..cda78e613 100644 --- a/dcat/index.html +++ b/dcat/index.html @@ -1133,7 +1133,7 @@

Property: update/modification date

Definition:Most recent date on which the item was changed, updated or modified. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]. (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime) + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:The value of this property indicates a change to the actual item, not a change to the catalog record. An absent value MAY indicate that the item has never changed after its initial publication, or that the date of last modification is not known, or that the item is continuously updated. See also:, and @@ -1570,7 +1570,7 @@

Property: listing date

Definition:The date of listing (i.e. formal recording) of the corresponding dataset or service in the catalog. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself. See also: @@ -1585,7 +1585,7 @@

Property: update/modification date

Definition:Most recent date on which the catalog entry was changed, updated or modified. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This indicates the date of last change of a catalog entry, i.e. the catalog metadata description of the dataset, and not the date of the dataset itself. See also: @@ -1984,7 +1984,7 @@

Property: release date

Definition:Date of formal issuance (e.g., publication) of the distribution. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). Usage note:This property SHOULD be set using the first known date of issuance. See also: @@ -1999,7 +1999,7 @@

Property: update/modification date

Definition:Most recent date on which the distribution was changed, updated or modified. Range:rdfs:Literal - encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). + encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). See also: @@ -2747,7 +2747,7 @@

Property: start date

Definition:The start of the period. Domain:dct:PeriodOfTime - Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). + Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]] (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime). From 0c3023e020309ebaf096b5bbc7ee253e0de9b63f Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Thu, 25 Jul 2019 22:02:29 +1000 Subject: [PATCH 13/26] minor change as requested by rob --- conneg-by-ap/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 7056a1f34..7a014e911 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -108,7 +108,7 @@

Definitions

This definition includes what are sometimes called "application profiles", "metadata application - profiles", or "metadata profiles". In this document, these, and "data profiles", are just referred to as just "profiles". + profiles", or "metadata profiles". In this document, these, and "data profiles", are all referred to as just "profiles".

Source: deliberations of the DXWG.

From 082870f2273347fb56022381a37562c2802f2273 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Sat, 27 Jul 2019 15:03:58 +1000 Subject: [PATCH 14/26] incomplete - placeholder note added --- conneg-by-ap/index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 6d7d921ee..d0660926f 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -167,10 +167,11 @@

Profiles for Conformance

If a system wishes to show conformance to this specification, conformance to at least one of the profiles listed in MUST be indicated.

- Another sentense/paragraph is needed here to indicate what shows conformance. It's not /a/resource's representation but something else as /a/resource + Another sentence/paragraph is needed here to indicate what shows conformance. It's not /a/resource's representation but something else as /a/resource may conform to some (data) profile but that data profile has nothing to do with CONNEG. It's the systems mechanics that are conformant here, unless we have a required resource that all implementations of this must implement that can describe the system function that conforms to the above.
+ THIS SPEC IS ABOUT CONFORMANCE TO DATA PROFILES BUT THIS CONFORMANCE PROFILE IS ABOUT A FUNCTIONAL PROFILE (LIKE WFS)
From 723ce62c4164f6ca0d35ea022bc13569caf67c5e Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Sat, 27 Jul 2019 15:13:17 +1000 Subject: [PATCH 15/26] dfn for specification added to list --- conneg-by-ap/index.html | 82 ++++++++++++++++++++++------------------- 1 file changed, 44 insertions(+), 38 deletions(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 495ffa840..06f8c332e 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -50,13 +50,13 @@

Introduction

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, 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 constrains 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, + 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 constrains 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.

@@ -71,10 +71,12 @@

Introduction

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.

- +

+ -->

Describing the parts of profiles and their relation to other profiles is the function of the Profiles Vocabulary [[PROF]], also produced by the DXWG. @@ -93,22 +95,26 @@

Introduction

Definitions

-
data specification
+
specification

- A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context. + A basis for comparison; a reference point against which other things can be evaluated. +

+

+ Source: DCMI Metadata Terms [[DCTERMS]]'s definition for a Standard.

+
+
data specification
+

- This document refers to both "data specifications" and also the more general "specifications". When the latter general case is referenced, its definition is taken - to be that of the DCMI Metadata Terms [[DCTERMS]]'s definition for a Standard, which is "A basis for comparison; a reference point against which other things - can be evaluated." + A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.

Source: deliberations of the DXWG.

data profile

- A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications. + A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.

This definition includes what are sometimes called "application profiles", "metadata application @@ -118,11 +124,11 @@

Definitions

client
- A program that establishes a connection to a server for the purpose of sending one or more HTTP requests. [[RFC7230]] + A program that establishes a connection to a server for the purpose of sending one or more HTTP requests. [[RFC7230]]
server
- A program that accepts connections in order to service HTTP requests by sending HTTP responses. [[RFC7230]] + A program that accepts connections in order to service HTTP requests by sending HTTP responses. [[RFC7230]]
resource
@@ -272,7 +278,7 @@

Using the Prefer/Preference-Applied header fields (RFC 7240)

Archival Resource Key (ARK)

ARK (Archival Resource Key) [[ARK]] is an identifier scheme for the persistent identification of information objects. - ARK identifiers can contain an optional qualifier + 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, a service provider offering ARK resolution) @@ -338,7 +344,7 @@

OAI-PMH

Catalogue Service for the Web (CSW)

[[CSW]] is the OGC standard used world-wide by the geospatial community to implement a machine-actionable interface - to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.), + to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.), 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 outputSchema and outputFormat 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 GetCapabilities request.

@@ -366,9 +372,9 @@

Context

An Internet resource may have many aspects over which a client/server pair of - agents might negotiate for content. These aspects are to be treated independently so content negotiation for a + agents might negotiate for content. These aspects are to be treated independently so content negotiation for a resource involving negotiation by profile and any other aspects of a resource will not affect - each other. For this reason, other than a directive to maintain independence, no further discussion of + each other. For this reason, other than a directive to maintain independence, no further discussion of negotiation by profile and the relations to other forms of negotiation are given. Specific realizations might require special handling of profile and other forms of negotiation.

@@ -410,13 +416,13 @@

Requests and Responses

A server adhering to this specification MUST respond to each request with the following - responses. + responses.

  1. list profiles
    a server responds to a client with the list of profile URIs for the profiles for which it is able to - deliver conformant resource representations + deliver conformant resource representations
  2. get resource by profile
    @@ -429,7 +435,7 @@

    Requests and Responses

    list profiles

    A client wishes to know for which profiles a server is able to deliver conformant - representations of a resource. The content of the list can be known either before a request for a + representations of a resource. The content of the list can be known either before a request for a particular resource representation is made or it may only be known after an initial request for a resource representation is made.

    @@ -715,21 +721,21 @@

    URL Query String Arguments

    - While the HTTP-header approach to profiles enables fully automated retrieval of data conforming - to a desired profile, it is also advisable to enable humans to select data by profile without - requiring direct manipulation of request header content. This can be accomplished by existing - web development methods where an API supports a graphical interface. The user can be presented - with a list of available profiles and given the choice of which to retrieve for the dataset of - interest. They can even be asked to indicate a ranked choice of possible profiles, which could - then be used to retrieve multiple resources' data matching a query. + While the HTTP-header approach to profiles enables fully automated retrieval of data conforming + to a desired profile, it is also advisable to enable humans to select data by profile without + requiring direct manipulation of request header content. This can be accomplished by existing + web development methods where an API supports a graphical interface. The user can be presented + with a list of available profiles and given the choice of which to retrieve for the dataset of + interest. They can even be asked to indicate a ranked choice of possible profiles, which could + then be used to retrieve multiple resources' data matching a query.

    - As one example of how an API for such a service can be implemented, a Query String Argument (QSA) - realization of the Abstract Model is presented here. Unlike the HTTP-header - realization, which is also the subject of an independent IETF document [[PROF-IETF]], this realization - is fully specified here but it is not normative. This realization does not preclude other URL schemes, - or even other QSA schemes, for profile negotiation, the general requirement being that any scheme - implements the functions of the Abstract Model. Whatever specific scheme is used, it should be fully + As one example of how an API for such a service can be implemented, a Query String Argument (QSA) + realization of the Abstract Model is presented here. Unlike the HTTP-header + realization, which is also the subject of an independent IETF document [[PROF-IETF]], this realization + is fully specified here but it is not normative. This realization does not preclude other URL schemes, + or even other QSA schemes, for profile negotiation, the general requirement being that any scheme + implements the functions of the Abstract Model. Whatever specific scheme is used, it should be fully documented and discoverable.

    @@ -855,7 +861,7 @@

    get resource by profile

    allow a client to specify a preference order for Media Types and also for other dimensions of content negotiation, such as language. When using a QSA-only API, Media Type preferences (and language and others in a similar fashion) can be specified in a comma-separated list form, most preferred to least, such that - a client requesting profiles as aaa,bbb,ccc will receive a resource that meets the requirements of profile + a client requesting profiles as aaa,bbb,ccc will receive a resource that meets the requirements of profile aaa if it is available, else one that meets profile bbb if that is available, and so on.

From 33f9de2daefc3b380d6c529b44369c3565b3edd4 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 12:32:38 +1000 Subject: [PATCH 16/26] aligned Acknowledgements somewhat with DCAT --- profilesont/index.html | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/profilesont/index.html b/profilesont/index.html index 692a24e9a..2c3e892b1 100644 --- a/profilesont/index.html +++ b/profilesont/index.html @@ -614,7 +614,7 @@

Property: isInheritedFrom

Usage note:This property is created for the convenience of clients. When profile describers wish to allow clients to discover all resources relevant to a Profile without having to navigating an inheritance hierarchy of prof:profileOf relations, this predicate may be used to directly associate inherited Profile Descriptors with the Profile. If this property is present, it should be used consistently and all relevant resources a client may need to utilise the profile should be present and described using this predicate -
+

To illustrate the use of prof:isInheritedFrom, the following example is given in both pictorial @@ -925,7 +925,7 @@

DCAT-AP

<https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f17e18570_b1d77_b4171_b9df5_bb53cb4f017d4> , # profile image (PNG) <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f1131a208_b92e9_b4427_ba40c_b6c47746cd422> , - # Constraints in SHACL + # Constraints in SHACL <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f016d88c3_ba0b3_b4506_bae4e_b758e7401c096> ; . @@ -955,7 +955,7 @@

DCAT-AP

dct:format <https://w3id.org/mediatype/image/png> ; prof:hasRole role:Guidance ; . - + <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f016d88c3_ba0b3_b4506_bae4e_b758e7401c096> a prof:ResourceDescriptor; rdfs:label "DCAT-AP Constraints" ; @@ -1594,19 +1594,19 @@

Appendices

Acknowledgements

- The editors acknowledge the chairs of this Working Group: Karen Coyle & Peter Winstanley and the staff - contact Dave Raggett. -

-

- The editors also gratefully acknowledge the contributions made to this document by all members of the Dataset - Exchange Working Group, specially the contributions received from Karen Coyle, Antoine Isaac, Andrea Perego and - Tom Baker. + The editors gratefully acknowledge the contributions made to this document by + all members of the working group, + especially Antoine Isaac, Tom Baker, Simon Cox, Alejandra Gonzalez-Beltran, Andrea Perego.

The editors would also like to thank non-members of this working group for their comments, changes and ideas from which have been incorporated into this document. In particular: Paul Walk, Leslie Sikos, Stephen Richard, Kam Hay Fung, Heidi Vanparys and Irene Polikoff.

+

+ Finally, the editors also gratefully acknowledge the chairs of this Working Group: Karen Coyle and Peter + Winstanley, former chair Caroline Burle and W3C staff contacts Phil Archer and Dave Raggett. +

From a2eb3e2e601eb5ac4f7753b99233fdeadebe1f8c Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 12:36:54 +1000 Subject: [PATCH 17/26] updated SVG image with white background --- profilesont/figures/isTransitiveProfileOf.svg | 425 +----------------- 1 file changed, 1 insertion(+), 424 deletions(-) diff --git a/profilesont/figures/isTransitiveProfileOf.svg b/profilesont/figures/isTransitiveProfileOf.svg index 8aecfed6a..08b6ab6f7 100644 --- a/profilesont/figures/isTransitiveProfileOf.svg +++ b/profilesont/figures/isTransitiveProfileOf.svg @@ -1,424 +1 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - isTransitiveProfileOf - - - - Rounded Rectangle.10 - owl:Class - - - - - - - - - - - - - - - - - - - - - - owl:Class - - Sheet.2 - Element Key - - - - Element Key - - Dynamic connector.4 - - - - Sheet.6 - rdf:type - - - - rdf:type - - Rounded Rectangle.218 - PROF class - - - - - - - - - - - - - - - - - - - - - - PROF class - - Rounded Rectangle.31 - owl: NamedIndividual - - - - - - - - - - - - - - - - - - - - - - owl:NamedIndividual - - Dynamic connector.64 - - - - Sheet.10 - rdf:property - - - - rdf:property - - Rounded Rectangle.12 - dct:Standard - - - - - - - - - - - - - - - - - - - - - - dct:Standard - - Rounded Rectangle.13 - Profile - - - - - - - - - - - - - - - - - - - - - - Profile - - Dynamic connector.15 - - - - Rounded Rectangle.16 - OWL Profile of ISO19160-1 - - - - - - - - - - - - - - - - - - - - - - OWL Profile of ISO19160-1 - - Dynamic connector.17 - - - - Rounded Rectangle.36 - New Zealand Profile of ISO19160-1 - - - - - - - - - - - - - - - - - - - - - - New Zealand Profile of ISO19160-1 - - Dynamic connector - is profile of - - - - - is profile of - - Dynamic connector.38 - is profile of - - - - - is profile of - - Rounded Rectangle.39 - ISO 19160-1:2015 Addressing - - - - - - - - - - - - - - - - - - - - - - ISO 19160-1:2015 Addressing - - Dynamic connector.40 - - - - Rounded Rectangle.48 - OWL - - - - - - - - - - - - - - - - - - - - - - OWL - - Dynamic connector.49 - - - - Dynamic connector.50 - is profile of - - - - - is profile of - - Dynamic connector.51 - - - - Dynamic connector.52 - is transitive profile of - - - - - is transitive profile of - - Sheet.55 - inferred - - - - inferred - - Dynamic connector.57 - - - - Dynamic connector.58 - - - - Dynamic connector.60 - is transitive profile of - - - - - is transitive profile of - - + \ No newline at end of file From 6535826abe1a8cae3b903f0070af390a81462f1b Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 13:02:22 +1000 Subject: [PATCH 18/26] Security & Privacy section as per DCAT & Conneg for Issue 479 --- profilesont/index.html | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/profilesont/index.html b/profilesont/index.html index 2c3e892b1..bc32a8307 100644 --- a/profilesont/index.html +++ b/profilesont/index.html @@ -1570,9 +1570,22 @@

Simple Knowledge Organization System

Security and Privacy

- + The PROF vocabulary, when used with likely extensions such as [[DCTERMS]], supports the attribution of data and + metadata to various participants such as resource creators, + publishers and other parties or agents via qualified + relations and, as such, may define terms that may be related to personal information. In addition, it may also + be used with extensions that support the association of rights and + licenses with modelled Profiles and Resource Descriptors. + These rights and licenses could potentially include or reference sensitive information such as user and asset + identifiers as described in [[ODRL-VOCAB]]. + Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security + and privacy considerations are addressed at the application level. +

+

+ For a more complete view of those issues, cf. the + + Security and Privacy Questionnaire for this specification.

-

Changes

From ff085ed067a081cb9dbbd4d92f58e61ba9272538 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 13:15:23 +1000 Subject: [PATCH 19/26] PROF profile descriptions removed --- conneg-by-ap/index.html | 118 ++++++++-------------------------------- 1 file changed, 22 insertions(+), 96 deletions(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index d0660926f..8755190f1 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -51,7 +51,7 @@

Introduction

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, 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 + 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.

@@ -155,9 +155,6 @@

Profiles for Conformance

of it. -

- Non-normative, formal, descriptions of the profiles in are given in . -

The namespace used for the above profiles, http://www.w3.org/ns/dx/conneg/profile/, is part of the Dataset Exchange Working Group's reserved W3C namespace, http://www.w3.org/ns/dx/, which is provisioned for all namespace requirements to do with issues addressed by that Working Group. The /profile/ path segment @@ -358,7 +355,7 @@

Using the Prefer/Preference-Applied header fields (RFC 7240)

Archival Resource Key (ARK)

ARK (Archival Resource Key) [[ARK]] is an identifier scheme for the persistent identification of information objects. - ARK identifiers can contain an optional qualifier + 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, a service provider offering ARK resolution) @@ -424,7 +421,7 @@

OAI-PMH

Catalogue Service for the Web (CSW)

[[CSW]] is the OGC standard used world-wide by the geospatial community to implement a machine-actionable interface - to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.), + to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.), 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 outputSchema and outputFormat 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 GetCapabilities request.

@@ -452,9 +449,9 @@

Context

An Internet resource may have many aspects over which a client/server pair of - agents might negotiate for content. These aspects are to be treated independently so content negotiation for a + agents might negotiate for content. These aspects are to be treated independently so content negotiation for a resource involving negotiation by profile and any other aspects of a resource will not affect - each other. For this reason, other than a directive to maintain independence, no further discussion of + each other. For this reason, other than a directive to maintain independence, no further discussion of negotiation by profile and the relations to other forms of negotiation are given. Specific realizations might require special handling of profile and other forms of negotiation.

@@ -496,13 +493,13 @@

Requests and Responses

A server adhering to this specification MUST respond to each request with the following - responses. + responses.

  1. list profiles
    a server responds to a client with the list of profile URIs for the profiles for which it is able to - deliver conformant resource representations + deliver conformant resource representations
  2. get resource by profile
    @@ -515,7 +512,7 @@

    Requests and Responses

    list profiles

    A client wishes to know for which profiles a server is able to deliver conformant - representations of a resource. The content of the list can be known either before a request for a + representations of a resource. The content of the list can be known either before a request for a particular resource representation is made or it may only be known after an initial request for a resource representation is made.

    @@ -801,21 +798,21 @@

    URL Query String Arguments

    - While the HTTP-header approach to profiles enables fully automated retrieval of data conforming - to a desired profile, it is also advisable to enable humans to select data by profile without - requiring direct manipulation of request header content. This can be accomplished by existing - web development methods where an API supports a graphical interface. The user can be presented - with a list of available profiles and given the choice of which to retrieve for the dataset of - interest. They can even be asked to indicate a ranked choice of possible profiles, which could - then be used to retrieve multiple resources' data matching a query. + While the HTTP-header approach to profiles enables fully automated retrieval of data conforming + to a desired profile, it is also advisable to enable humans to select data by profile without + requiring direct manipulation of request header content. This can be accomplished by existing + web development methods where an API supports a graphical interface. The user can be presented + with a list of available profiles and given the choice of which to retrieve for the dataset of + interest. They can even be asked to indicate a ranked choice of possible profiles, which could + then be used to retrieve multiple resources' data matching a query.

    - As one example of how an API for such a service can be implemented, a Query String Argument (QSA) - realization of the Abstract Model is presented here. Unlike the HTTP-header - realization, which is also the subject of an independent IETF document [[PROF-IETF]], this realization - is fully specified here but it is not normative. This realization does not preclude other URL schemes, - or even other QSA schemes, for profile negotiation, the general requirement being that any scheme - implements the functions of the Abstract Model. Whatever specific scheme is used, it should be fully + As one example of how an API for such a service can be implemented, a Query String Argument (QSA) + realization of the Abstract Model is presented here. Unlike the HTTP-header + realization, which is also the subject of an independent IETF document [[PROF-IETF]], this realization + is fully specified here but it is not normative. This realization does not preclude other URL schemes, + or even other QSA schemes, for profile negotiation, the general requirement being that any scheme + implements the functions of the Abstract Model. Whatever specific scheme is used, it should be fully documented and discoverable.

    @@ -941,7 +938,7 @@

    get resource by profile

    allow a client to specify a preference order for Media Types and also for other dimensions of content negotiation, such as language. When using a QSA-only API, Media Type preferences (and language and others in a similar fashion) can be specified in a comma-separated list form, most preferred to least, such that - a client requesting profiles as aaa,bbb,ccc will receive a resource that meets the requirements of profile + a client requesting profiles as aaa,bbb,ccc will receive a resource that meets the requirements of profile aaa if it is available, else one that meets profile bbb if that is available, and so on.

@@ -1044,77 +1041,6 @@

Security and Privacy

Appendices

-
-

Profiles of this specification

-

- This specification contains a number of distinct profiles that are identified and described in words in . This appendix presents descriptions of - these profiles, and the relations between them, according to the Profiles Vocabulary [[PROF]]. -

- 
-@prefix dct: <http://purl.org/dc/terms/> .
-@prefix prof: <http://www.w3.org/ns/dx/prof/> .
-@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix cnpr: <http://www.w3.org/ns/dx/conneg/profile/> .
-
-<https://www.w3.org/TR/dx-prof-conneg/> a dct:Standard ;
-    rdfs:label "Content Negotiation by Profile" ;
-    rdfs:comment "The W3C Recommendation (a standard) for Content Negotiation by Profile" .
-
-cnpr:abstract a prof:Profile ;
-    prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ;
-    rdfs:label "Abstract Model Profile" ;
-    rdfs:comment "Abstract Model profile of Content Negotiation by Profile" .
-
-cnpr:http a prof:Profile ;
-    prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ;
-    rdfs:label "HTTP Realization Profile" ;
-    rdfs:comment "HTTP Realization profile of Content Negotiation by Profile" .
-
-cnpr:qsa a prof:Profile ;
-    prof:isProfileOf <http://www.w3.org/ns/dx/conneg/profile/abstract> ;
-    rdfs:label "QSA Realization Profile" ;
-    rdfs:comment "QSA Realization profile of Content Negotiation by Profile" .
-
-cnpr:qsa-alt a prof:Profile ;
-    prof:isProfileOf <http://www.w3.org/ns/dx/conneg/profile/abstract> ;
-    rdfs:label "QSA Alternate Keywords Realization Profile" ;
-    rdfs:comment "Query String Argument Alternate Keywords Realization profile of Content Negotiation by Profile" .
-
-cnpr:rrd a prof:Profile ;
-    prof:isProfileOf <https://www.w3.org/TR/dx-prof-conneg/> ;
-    rdfs:label "Resource Representation Description Profile" ;
-    rdfs:comment "Resource Representation Description profile of Content Negotiation by Profile" .
-
-

- The code listing describes this Content Negotiation by Profile specification as a - dct:Standard and the 5 profiles of it in a profile hierarchy with the Abstract Model and Resource Representation Description - profiles profiling the specification directly and the other four profiles profiling the Abstract Model profile. This is shown graphically in below. -

-
- Profile hierarchy of this specification -
- The specification and profiles of this Content Negotiation by Profile standard shown in a [[PROF] profiles hierarchy. -
-
-
-

Demonstrating conformance to profiles

-

- With the identification of profiles of this specification given in and their description of them using the Profiles Vocabulary [[PROF]] in this - appendix, it is possible for services that deliver content according to the specification or any of the profiles to show conformance to the specification or any of the profiles by - using the same mechanisms recommended in [[PROF]] for a data resource to show conformance to a profile. For data resources, the recommendation is that they declare an RDF statement - such as </a/resource> dct:conformsTo <SPEC_OR_PROFILE_URI> .. This, adapted for use with services, is shown in . -

- 
-@prefix dct: <http://purl.org/dc/terms/> .
-@prefix cnpr: <http://www.w3.org/ns/dx/conneg/profile/> .
-
-<XXXX> dct:conformsTo cnpr:qsa-alt .
-
-

- The information in can be used to... -

-

Requirements

From 48e61a26591a7b58a9d91f416189870dbf251420 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 13:20:06 +1000 Subject: [PATCH 20/26] note indicating this spec is a functional spec, not data spec --- conneg-by-ap/index.html | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 8755190f1..6f0e90baf 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -164,11 +164,10 @@

Profiles for Conformance

If a system wishes to show conformance to this specification, conformance to at least one of the profiles listed in MUST be indicated.

- Another sentence/paragraph is needed here to indicate what shows conformance. It's not /a/resource's representation but something else as /a/resource - may conform to some (data) profile but that data profile has nothing to do with CONNEG. It's the systems mechanics that are conformant here, unless we have a required - resource that all implementations of this must implement that can describe the system function that conforms to the above. + This section's identifications of profiles of this specification exemplifies functional profiles which profile a functional specification, rather than a + data profile which profiles a data specification. This specification describes how a system should behave and this section indicates different profiles of that behaviour, rather + than content (data).
- THIS SPEC IS ABOUT CONFORMANCE TO DATA PROFILES BUT THIS CONFORMANCE PROFILE IS ABOUT A FUNCTIONAL PROFILE (LIKE WFS)
From 6a634569a5ac4beaa789929ee564fbd164905c0d Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 13:26:20 +1000 Subject: [PATCH 21/26] replaced "NB" not with class note --- conneg-by-ap/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 6f0e90baf..629e8f17a 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -84,7 +84,7 @@

Introduction

Section 7 and Section 8.

-

NB Profiles and specifications embody their own notions of conformance (of data), which are out of scope for this document.

+

Specifications and Profiles embody their own notions of conformance, which are out of scope for this specification.

Profiles for Conformance

From fe8640d14e973b08dbc21592709e5aa939564973 Mon Sep 17 00:00:00 2001 From: Nicholas Car Date: Mon, 29 Jul 2019 13:55:30 +1000 Subject: [PATCH 22/26] example as per Issue 287 --- conneg-by-ap/index.html | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/conneg-by-ap/index.html b/conneg-by-ap/index.html index 06f8c332e..d0125cf97 100644 --- a/conneg-by-ap/index.html +++ b/conneg-by-ap/index.html @@ -477,9 +477,9 @@

get resource by profile

anything that the profile profiles (a more general specification or profile), perhaps transitively.

- If a client requests a profile but gets a narrower profile, the Server should set its responses - Content-Profile header to the profile identifier that the Client requested, not the identifier of the - narrower profile as the client might not understand the narrower profile identifier. + A server SHOULD set a Content-Profile header in HTTP response to the profile + identifier (URI) that the Client requested, not the identifier of any narrower profile that is also applicable + since the client might not understand the narrower profile identifier. 

 # a request for Resource 1 according to Profile A is made
@@ -502,11 +502,28 @@ 
get resource by profile

 
 HTTP/1.1 200 OK
 [other response headers]
-Content-Profile: http://example.org/profile/A
+Content-Profile: <http://example.org/profile/A>
 [more response headers]
 
 [content according to Profile B and thus Profile A which it profiles]
+

+ When a resource is returned that conforms to two or more profiles not within a profile hierarchy + (i.e. none of the multiple profiles the resource conforms to is a profiles of another), the server MUST + indicate all profiles individually within the Content-Profile header as such: +

+

+ Content-Profile: <PROFILE_1>, <PROFILE_2> +

+

+ 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 DCAT-AP Hierarchy + example in [[PROF]]), using profile URIs for [[?GeoDCAT-AP]] and [[?statdcat-ap]] could be: +

+

+ Content-Profile: <https://joinup.ec.europa.eu/release/geodcat-ap-v10>, <https://joinup.ec.europa.eu/release/statdcat-ap/101> +

@@ -592,7 +609,7 @@

list profiles

HTTP/1.1 200 OK Content-Type: text/turtle Content-Location: http://example.org/a/resource.prof1.ttl -Content-Profile: urn:example:profile:1 +Content-Profile: <urn:example:profile:1> Link: <http://example.org/a/resource.prof1.ttl>; rel="self"; type="text/turtle"; profile="urn:example:profile:1", <http://example.org/a/resource.prof2.ttl>; rel="alternate"; type="text/turtle"; profile="urn:example:profile:2", <http://example.org/a/resource.prof1.xml>; rel="alternate"; type="application/xml"; profile="urn:example:profile:1", @@ -623,7 +640,7 @@

Token mappings

HTTP/1.1 200 OK Content-Type: text/turtle Content-Location: http://example.org/a/resource.prof1.ttl -Content-Profile: urn:example:profile:1;token=p1 +Content-Profile: <urn:example:profile:1;token=p1> Link: <http://example.org/a/resource.prof1.ttl>; rel="self"; type="text/turtle"; profile="urn:example:profile:1;token=p1", <http://example.org/a/resource.prof2.ttl>; rel="alternate"; type="text/turtle"; profile="http://example.org/profile/2;token=p2", <http://example.org/a/resource.prof1.xml>; rel="alternate"; type="application/xml"; profile="urn:example:profile:1;token=p1", @@ -646,7 +663,7 @@

Option 1: token parameters (recommended)

Option 2: registered tokens

Tokens are registered in a global registry and servers may use them in place of a URI
- Content-profile: token1, URI2 + Content-profile: token1, <URI2> Pros: compact
Cons: a global registry for profiles not manageable when many systems define profiles and such a registry limits other capabilities of profile description by forcing generic profiles @@ -706,7 +723,7 @@

get resource by profile

HTTP/1.1 200 OK Content-Type: text/turtle -Content-Profile: urn:example:profile:1 +Content-Profile: <urn:example:profile:1> [more response headers]

From 1bae1e20a553092adb7b429ffce3a36202ed1388 Mon Sep 17 00:00:00 2001 From: Andrea Perego Date: Tue, 30 Jul 2019 18:13:43 +0200 Subject: [PATCH 23/26] DCAT: Ack section updated As per https://github.com/w3c/dxwg/issues/945 --- dcat/index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dcat/index.html b/dcat/index.html index 75aea7b71..0cc68c142 100644 --- a/dcat/index.html +++ b/dcat/index.html @@ -4042,9 +4042,9 @@

Security and Privacy

Acknowledgments

-

The editors gratefully acknowledge the contributions made to this document by all members of the working group, especially Annette Greiner, Antoine Isaac, Dan Brickley, Ine de Visser, Jaroslav Pullmann, Makx Dekkers, Nicholas Car, Rob Atkinson.

+

The editors gratefully acknowledge the contributions made to this document by all members of the working group, especially Annette Greiner, Antoine Isaac, Dan Brickley, Ine de Visser, Jaroslav Pullmann, Linda van den Brink, Makx Dekkers, Nicholas Car, Rob Atkinson.

-

The editors would also like to thank comments received from Andreas Kuckartz, Armando Stellato, Bert van Nuffelen, Chris Sweeney, Clemens Portele, Daniel Pop, Guillaume Duffes, Ian Davis, Jakob Voß, Jakub Klímek, Leigh Dodds, Luca Trani, Marco Brattinga, Melanie Barlow, Nuno Freire, Pano Maria, Peter Parslow, Stephane Fellah, Stephen Richard, Stijn Goedertier, Vladimir Alexiev.

+

The editors would also like to thank comments received from Addison Phillips, Andreas Kuckartz, Armando Stellato, Bert van Nuffelen, Chris Sweeney, Chris Wood, Clemens Portele, Daniel Pop, Guillaume Duffes, Ian Davis, Jakob Voß, Jakub Klímek, James Passmore, Leigh Dodds, Luca Trani, Marco Brattinga, Melanie Barlow, Nuno Freire, Pano Maria, Peter Parslow, Renato Iannella, Ruth Duerr, Siri Jodha S. Khalsa, Stephane Fellah, Stephen Richard, Stijn Goedertier, Vladimir Alexiev, Yves Coene.

The editors also gratefully acknowledge the chairs of this Working Group: Karen Coyle, Caroline Burle and Peter Winstanley — and staff contacts Phil Archer and Dave Raggett.

From 94ccfca8cd97705a911540da4e70ff768ba26506 Mon Sep 17 00:00:00 2001 From: Andrea Perego Date: Tue, 30 Jul 2019 18:21:02 +0200 Subject: [PATCH 24/26] Minor editorial changes One addressing point 4 in https://github.com/w3c/dxwg/issues/1020#issue-474066926 --- dcat/index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dcat/index.html b/dcat/index.html index 0cc68c142..8df49df44 100644 --- a/dcat/index.html +++ b/dcat/index.html @@ -828,7 +828,7 @@

Property: themes

Usage note: - It is recommended that the taxonomy is organized in a skos:ConceptScheme, skos:Collection, owl:Ontology or similar, which allows each member to be denoted by an IRI and published as linked-data. + It is recommended that the taxonomy is organized in a skos:ConceptScheme, skos:Collection, owl:Ontology or similar, which allows each member to be denoted by an IRI and published as Linked Data. @@ -2367,7 +2367,7 @@

Property: endpoint URL

- + @@ -3917,7 +3917,7 @@

Relationships between datasets and agents

- In the roles are taken from [[?ISO-19115-1]] which are available as linked data in a code list. + In the roles are taken from [[?ISO-19115-1]] which are available as Linked Data in a code list.

RDF Property:dcat:endpointURL
Definition:The root location or primary endpoint of the service (a web-resolvable IRI).
Definition:The root location or primary endpoint of the service (a Web-resolvable IRI).
Domain:dcat:DataService
Range:rdfs:Resource
- + @@ -982,7 +982,7 @@

Class: Cataloged Resource

This class carries properties common to all cataloged resources, including datasets and data services. It is strongly recommended to use a more specific sub-class. When describing a resource which is not a dcat:Dataset or dcat:DataService, it is recommended to create a suitable sub-class of dcat:Resource, or use dcat:Resource with the dct:type property to indicate the specific type. - +
RDF Property:dcat:catalog
Definition:A catalog whose contents are of interest in the context of this catalog
Definition:A catalog whose contents are of interest in the context of this catalog.
Sub-property of:dct:hasPart
Domain:dcat:Catalog
Range:dcat:Catalog
Usage note:dcat:Resource is an extension point that enables the definition of any kind of catalog. Additional sub-classes may be defined in a DCAT profile or other DCAT application for catalogs of other kinds of resources
Usage note:dcat:Resource is an extension point that enables the definition of any kind of catalog. Additional sub-classes may be defined in a DCAT profile or other DCAT application for catalogs of other kinds of resources.
See also:
@@ -3881,7 +3881,7 @@

Qualified relations