Merge pull request #3 from netwerk-digitaal-erfgoed/suggestions

some suggestions for updating the text

README.md

@@ -24,7 +24,7 @@ Heritage institutions must use Persistent Identifiers (PIDs) for their resources
 
 There are multiple PID systems such as [Archival Resource Keys](https://arks.org) (ARKs), [Digital Object Identifiers](https://www.doi.org) (DOIs), [Handle](http://handle.net) and others. You may chose the implementation. Each system has its own particular properties, strengths, and weaknesses. Our [PID Guide](https://www.pidwijzer.nl/en) helps you make a choice. 
 
-As a heritage institution you must chose a PID system. You may be limited by the PID systems supported by your software vendor. But when you change vendor, your PID system migrates with you. 
+As a heritage institution you must chose a PID system. You may be limited by the PID systems supported by your software vendor. But when you change vendor, your PID system migrates with you. You may build your own system for ensuring the sustainability of your identifiers. In that case you must document the measures you take to garantee the sustainability. For all systems you should formaly describe the policies on how you intend to keep the PIDs functioning over time. 
 
 As a vendor you must implement at least one PID system in your software. You may support more. When implementing the PID-system you must link resources to your customer (the cultural heritage institution) and not to you as a vendor. Persistency must be guaranteed when resources are migrated to another vendor in the future.
 
@@ -45,24 +45,22 @@ You must use the generic model [schema.org](https://schema.org) when you chose t
 We recommend you also serve data in one or more domain models. Domain models make reuse of data much more likely and may contain a wealth of information. Depending on the type of data, you may consider the following examples:
 - Museum collections and catalogues: [CIDOC-CRM](https://cidoc-crm.org) and its derivative [Linked-Art](https://linked.art/model/).
 - Data from archives: [RiC-O](https://www.ica.org/standards/RiC/RiC-O_v0-2.html)
-- Libraries: [BIBFRAME](https://www.loc.gov/bibframe/) or [RDA Elements](https://www.rdaregistry.info/Elements/)
+- Libraries: [RDA Elements](https://www.rdaregistry.info/Elements/) following the recommendations of the [RDA application profile Dutch bibliography (only in Dutch)](https://netwerk-digitaal-erfgoed.github.io/rdanl/). When using other library domain standards like [BIBFRAME](https://www.loc.gov/bibframe/) you should document the implementation choices made and relation to the RDA application profile.
 
-You may also implement any model suggested by [CLARIAH](https://www.clariah.nl) in the [Awesome Ontologies for Digital Humanities](https://github.com/CLARIAH/awesome-humanities-ontologies) repository.
-
-You should implement the [W3C draft for content negotiation by profile](https://www.w3.org/TR/dx-prof-conneg/) when publishing linked data that is available in multiple models.
+When recommend to publish documentation about the mapping of your data (recommended in a machine readable format) to other well known models like the [Europeana Data Model (EDM)](https://pro.europeana.eu/page/edm-documentation). You can get support from NDE for creating these mappings.   
 
 #### 2.2 Serving data
 
 The [Implementation Guidelines](https://netwerk-digitaal-erfgoed.github.io/cm-implementation-guidelines/#publishing-collection-information) mentioned earlier consider three levels when [publishing linked data](https://netwerk-digitaal-erfgoed.github.io/cm-implementation-guidelines/#publishing-linked-data):
-1. Basic level: data dumps
-2. Web compliance level: resolvable URIs
+1. Web compliance level: resolvable URIs
+2. Basic level: data dumps
 3. Advanced level: queryable Linked Data
 
 You must publish linked data both as level 1 and 2. 
 
-To publish linked data as a data dump (level 1) you should use [RDF](https://www.w3.org/RDF/) or [JSON-LD](https://json-ld.org) as a format.  You are required to serve the data dump through a [persistent identifier](###%201.%20Persistent%20Identifiers). To handle requests you must provide an API that complies with the [Open API Specification](https://spec.openapis.org/oas/latest.html). 
+To publish web compliant linked data (level 1) you must use persistent identifiers (see above) to resolve the individual linked data resources contained in your data. To handle requests you must support the [HTTP Content Negotation functionality](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3) which offers users the choice to consume the data in HTML or RDF serializations.
 
-To publish web compliant linked data (level 2) you must use persistent identifiers (see above) to resolve the individual linked data resources contained in your data. To handle requests you must provide an API that complies with the [Open API Specification](https://spec.openapis.org/oas/latest.html). 
+To publish linked data as a data dump (level 2) you should use [RDF](https://www.w3.org/RDF/). We recommend the use of the N-Triples serialisation for flexibility but any valid RDF serialisation is valid (N-Triples, Turtle, JSON-LD, RDF/XML). You are required to serve the data dump through a [persistent identifier](###%201.%20Persistent%20Identifiers). 
 
 We strongly recommend that vendors implement level 3 in their products and allow users to also query linked data collections. For compliance with level 3 you must use a [SPARQL](https://www.w3.org/TR/rdf-sparql-query/) endpoint.
 
@@ -72,7 +70,7 @@ We strongly recommend that vendors implement level 3 in their products and allow
 
 To increase the findability of datasets of heritage institutions, you must also publish the metadata of any dataset you serve. The metadata contains the description of the dataset and must be modelled in [schema.org](https://schema.org). We created a data model for the description of datasets and have adopted the class https://schema.org/Dataset. You must comply with the model as documented in the [NDE Requirements for Datasets](https://netwerk-digitaal-erfgoed.github.io/requirements-datasets) and specifically the [section Dataset information](https://netwerk-digitaal-erfgoed.github.io/requirements-datasets/#dataset-information).
 
-You are required to serve the metadata through a [persistent identifier](###%201.%20Persistent%20Identifiers). To handle requests you must provide an API that complies with the [Open API Specification](https://spec.openapis.org/oas/latest.html). 
+You are required to serve the metadata through a [persistent identifier](###%201.%20Persistent%20Identifiers). 
 
 You must publish metadata with an open data license. You may chose the most suitable license.
 
@@ -84,11 +82,11 @@ Remember that you must relate a license to the dataset, the object metadata, and
 
 To connect the linked data that you publish with other data sources you should use terms. Terms are descriptions of concepts or entities, such as subjects, people or places, and are managed in terminology sources, such as thesauri, reference lists or classification systems. Examples are [AAT](https://www.getty.edu/research/tools/vocabularies/aat/), [GeoNames](https://www.geonames.org/) or [WO2 Thesaurus](https://data.niod.nl/WO2_Thesaurus.html) (in Dutch).
 
-You may use your own terminology sources. However, you reduce the ability to connect to sources from different institutions when using terms that are not part of internationally standardised terminology sources. We recommend using as many standardised terminology sources as possible. If you are considered an authority in your domain, you should publish your own terminology source for use by others. Please refer to our [Implementation Guidelines on publishing terminology sources](https://netwerk-digitaal-erfgoed.github.io/cm-implementation-guidelines/#publishing-terminology-sources). 
+You may use your own terminology sources. However, you reduce the ability to connect to sources from different institutions when using terms that are not part of internationally standardised terminology sources. We recommend using as many standardised terminology sources as possible. We developped the Netork-of-Terms service to give easy access to many different terminology sources.
 
-As a vendor you must implement configurable terms for fields in your heritage application. You may chose the specific fields. If you allow users of your application to configure the data type of a field, you should add a data type for terms. That way users are not limited in the (number of) fields that they want to configure for certain sets of terms.
+ If you are considered an authority in your domain, you should publish your own terminology source for use by others and make it available through the Network-of-Terms. Please refer to our [Implementation Guidelines on publishing terminology sources](https://netwerk-digitaal-erfgoed.github.io/cm-implementation-guidelines/#publishing-terminology-sources). 
 
-It is not recommended that you import the lists of terms in your system. A limitation of such imports is that the user does not view the current data and you must periodically synchronise with the sources of each set of  terms. Wherever possible you should query terminology sources real-time. We recommend using the [NDE Network of Terms](https://termennetwerk.netwerkdigitaalerfgoed.nl/faq)to help you avoid having to establish multiple connections to a range of data sources serving terms, . 
+For vendors we require the implementation of the [NDE Network of Terms API](https://termennetwerk.netwerkdigitaalerfgoed.nl/faq) in the collection management system. This will give your customers easy access to a wide range of terminology sources made available through the Network-of-Terms. You must implement configurable terms for fields in your heritage application. You may chose the specific fields. If you allow users of your application to configure the data type of a field, you should add a data type for terms. That way users are not limited in the (number of) fields that they want to configure for certain sets of terms. 
 
 ### 4. Registration with the NDE dataset register
 
@@ -106,4 +104,4 @@ We use the [IIIF Image API Validator](https://iiif.io/api/image/validator/) to t
 
 While the Image API provides access to individual images, it does not describe the relationship between groups of images, such as the individual scans that make up the pages of a book. Besides the IIIF Image API you must also publish a IIIF manifest through the [IIIF Presentation API](https://iiif.io/api/presentation/3.0/). A IIIF manifest is a JSON-LD document that describes the structure and metadata of a digital object or collection of objects, such as images, audio, or video. It is comprises several key components, including pages, canvases, table of contents (ranges), and annotations.
 
-We use the [IIIF Presentation API Validator](https://presentation-validator.iiif.io) to test compliance.
+We use the [IIIF Presentation API Validator](https://presentation-validator.iiif.io) to test compliance.