mobilitydcat-ap/mobilitydcat-ap

Repository of the metadata specification mobilityDCAT-AP

mobilityDCAT-AP

This is the issue tracker for the maintenance of mobilityDCAT-AP.

mobilityDCAT-AP is an extension of DCAT-AP for describing mobility datasets, dataset series, and services. It provides an RDF syntax binding for the union of metadata elements defined in the National Access Points across Europe. Its basic use case is to make mobility datasets, data series, and services searchable on general data portals, thereby making mobility information better searchable across borders and sectors.

mobilityDCAT-AP is an initiative of the NAPCORE (National Access Point Coordination Organisation for Europe), a formed organisation to coordinate and harmonise more than 30 mobility data platforms across Europe.

The latest version of the mobilityDCAT-AP (v1.0.0) is available:

https://w3id.org/mobilitydcat-ap/releases/

Any problems encountered or suggestions for new functionalities can be submitted as issues on the mobilityDCAT-AP repository on GitHub. A short guideline for submitting issues can be found at SEMICeu/DCAT-AP/wiki/Submission-guidelines.

The guidelines about the mobilityDCAT-AP specification are available at mobilityDCAT‐AP Accompanying Guidelines

Structure of the repository

• Releases: mobilityDCAT-AP releases (1.0.0, etc.); each release might have different distributions.
• Working Drafts: Working drafts including revisions to the latest mobilityDCAT-AP release.

Licence

Copyright © 2023 NAPCORE. All material in this repository is published under the licence CC BY 4.0, unless explicitly otherwise mentioned. Any problems encountered, or suggestions for new functionalities can be submitted as issues on the mobilityDCAT-AP repository on GitHub.

mobilitydcat-ap's Issues

Future usage of property "conditions for access and usage"

For Distributions, we have the mandatory property "dct:rights" with cardinality 1..1.
This leads to class "Rights Statement", which has a mandatory property "conditions for access and usage".
For this property, we are using the following Controlled Vocabulary:
https://mobilitydcat-ap.github.io/controlled-vocabularies/conditions-for-access-and-usage/latest/index.html#/

This Vocabulary is denoting pre-defined categories of "conditions for access and usage". The origin of this property and its Vocabulary is the Coordinated Metadata Catalogue. We took this over via the Conceptual Model, but made the value list a little more generic.

Old value list (CMC):

• No licence – No contract
• Licence and Free of charge
• Licence and Fee
• Contract and Free of charge
• Contract and Fee
• Not relevant

Current value list (our Controlled Vocabulary):

• Licence provided
• Contractual arrangement
• Free of charge
• Fee required
• Royalty-free
• Other

However, there are some observations:

• The above value list is rarely used as metadata fields in existing NAPs.
• For new NAPs (e.g., in DK), it seems that concrete licenses are preferred (via another property "dct:license").
• Our value list seems a little naive (it has never been discussed with license experts). For example, there might be a combination of the values "Licence provided" and "Free of charge", which is not allowed with cardinality 1..1.

Options:

• Check and verify the current value list
• Change cardinality to 1..n.
• Make property recommended (instead mandatory) with cardinality 0..n.

Dataset class: mandatory frequency proprety

Dear

I noticed in your mobilityDCAT-AP profile frequency property is a MUST in the meaning of 1st section of RFC 2119 in the definition of the Dataset object type.

This is a clear restriction regarding to DCAT AP specifications as both DCAT AP 2 and 3 set this property as OPTIONNAL in the meaning of ther 5th section of RFC 2119.

Therefore I would align the requirement

I think this is a very surprising position as that property is "Recommended" in the current version of DCAT AP 3 (https://semiceu.github.io/DCAT-AP/releases/3.0.0/#quick-reference). Many data provider in my country do not maintain such an information. Moreover this is not a metadata element that is required for INSPIRE dataset which means INSPIRE datasets won't have such a property on the one hand or this will go against once only principle on the other hand.

Therefore I strongly recommend to specify this property as OPTIONNAL or as RECOMMANDED in the meaning of 5th and 3rd sections of RFC 2119.

Regards,

Dataset class: mobility theme

Dear

I noticed in your mobilityDCAT-AP profile moility themeproperty is a MUST in the meaning of 1st section of RFC 2119 in the definition of the Dataset object type.

This is a from new property added by Mobility DCAT AP which becomes an extension of DCAT AP rather than an application profile or a specification. In my opinion this is not a good practice at all and this is to be avoided as that new attribute won't be understood or taken into account by most of its readers that don't expect such an attribute.

Therefore I strongly recommend to stick to the theme property that had been designed for that purpose by both DCAT an DCAT AP custodians. If you want a specific vocab to be mentioned (i.e. your own vocab) you should require as a MUST in the meaning of the 1st section of RFC 2119 the skos:inScheme property in the skos:Concept object type and you should ask for an unambiguous reference to that specific vocab in that property. This is much more interoperable and standard and once only friendly way of specifying a vocab.

Regards,

Create documentation of the mobilityDCAT-AP vocabulary

Document the mobilityDCAT-AP vocabulary by using standard tools for documenting ontologies and controlled vocabularies.
First, create the vocabulary file based on the "Conceptual Model for mobilityDCAT-AP - Essential Metadata Elements" file.
Then generate the technical documentation associated with it.

Define folder structure for versioned drafts/releases

The current .htaccess defined for w3id takes into account the structure of versioned drafts/releases of GeoDCAT-AP. To be discussed if something should be changed.

For example versioned drafts are saved as drafts/1.1-draft-0.1, i.e., drafts/version-draft-0.1

Evolution of mobilityDCAT-AP vs. our Controlled Vocabs

So far, we have published an initial release of mobilityDCAT-AP and some own Controlled Vocabularies. Everything is in v1.0.0.
But now, we face an evolution:

• mobilityDCAT-AP will be updated as 1.0.0 -> 1.0.1
• One of our Controlled Vocab has a minor error, i.e., will be updated as 1.0.0 -> 1.0.1
• The other of our Controlled Vocabs will remain as 1.0.0.

In the end, there might be a different pace of evolution for mobilityDCAT-AP vs. our Controlled Vocabularies.
So far, the idea is that everything is independent, meaning that mobilityDCAT-AP and our Controlled Vocabularies can be updated independently.
We can keep it this way with the following benefits:

• we can do updates of our Controlled Vocabs, without "waiting" for updates of mobilityDCAT-AP, or vice versa.
• users have the freedom to deploy ANY version of mobilityDCAT-AP in combination with ANY version of our Controlled Vocabs

However, this implies:

• We need to carefully inform about this "independent approach", and any updates of mobilityDCAT-AP AND our Controlled Vocabularies.
• We need to provide online any older versions of mobilityDCAT-AP AND our Controlled Vocabularies (so users still can upgrade step-by-step).

Any thoughts or oppositions?

Dataset property dct:language is mandatory, does not explain what to do if a dataset has no language

The comment for this property says "This property refers to a language of content data, if this data has a natural language embedded."
If we are going to keep this property as mandatory, there must be some guidance for how to fill it in for data that do not have a natural language embedded.

language | dct:language | dct:LinguisticSystem | This property refers to a language of content data, if this data has a natural language embedded. Such data contents include text fields, addresses etc. This property can be repeated if there are multiple languages in the Dataset - see § 8. Accessibility and Multilingual Aspects. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

mobilitydcatap:mobilityDataStandard and mobilitydcatap:MobilityDataStandard

In the specification, in some cases, the wrong URI is used for the class mobilitydcatap:MobilityDataStandard, e.g., in https://mobilitydcat-ap.github.io/mobilityDCAT-AP/releases/index.html#properties-for-mobility-data-standard. The URI with the uppercase "M" should be used for the class and the one with the lowercase "m" for the property.

Further questions and remarks from SEMIC

Dear all,
In addition to the comments by Makx Dekkers (see my other issue), I had a call today with the entire SEMIC team.
They identified some points in our latest draft of mobilityDCAT-AP v1.0, which might create interoperability issues in the DCAT-AP ecosystem. For instance, when datasets are both in "our" scope (ITS Directive) and other frameworks (e.g. the High Value Dataset directive).

I noted the following points and proposed solutions.
As this is a last-minute action for our v1.0 revision, please comment/reply by Sept. 20th at the latest.

Property "contact point"

We removed the "contact point" property...
https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#recommended-properties-for-dataset
... and concentrate any contact details under the roles associated with the class "Agent" , e.g. :
https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#dataset-publisher

SEMIC emphasizes the "contact point" as the main property to establish a direct interaction to the data provider, whereas "Agent" should be the official entity behind the data provider. The "contact point" might be more specific, sometimes volatile or even external of the official entity.

-> We will re-introduce "contact point" under class "Dataset", and revise chapter 7.

Class "Data Service"

We recommend not using the class "Data Service"...
https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#properties-for-data-service
...but recommend declaring endpoint-APIs and similar under class "Distribution".
We optionally allow having class "Data Service" as a link to a "Distribution", creating a 4-layer-hierarchy "Catalogue Record"->"Dataset"->"Distribution"->"Data Service" (whereas the latter one is optional).

DCAT-AP introduced class "Data Service" by purpose, as an equivalent to a "Dataset" being described in a catalogue, in case data is provided via APIs etc. A sole usage of the Dataset->Distribution concept for such provision forms is seen outdated.

-> We will refine the usage note under class "Data Service" and state that any constellations using this class (even behind the 4-layer-hierarchy) are allowed, however noting that the 4-layer-hierarchy represent the status-quo of NAPs so far.

Properties "rights" vs. "licence"

We allow both, whereas the first one is obligatory, the second one recommended.

SEMIC argues that "licence" is the most-granular information possible, denoting concrete licences in machine- and human-readable formats. Thus, this is preferred. In contrast, "rights" is used when no specific information on licensing is available.

->This does not contradict to our understanding. However, I will make this more clear in the usage notes.

Property "theme"

We allow an proprietary (granular) Controlled Vocab, as an addition to the (rough) vocab of the EU Authority List. Both are linked via the same property "dcat:theme".

SEMIC recommends to align any theme definitions, when datasets address more than one domain (e.g. geo AND mobility). In general, a super-vocab should be valid for each domain, and sub-domains might introduce own vocabs, However, different properties should be used to better distinguish different layers of vocabs,

-> I stated this is exactly what we are proposing: two vocabs are noted for "dcat:theme" under chapter 5.2. I will introduce a new property "mobilitydcatap:mobilityTheme", as s sub-property to "dcat:theme", which will link to our proprietary vocab.

Property "frequency"

We link this to a Controlled Vocab from the EU Authority List. Because this vocab is missing some values that we need, we added another proprietary vocab. Both vocabs together provide the entire list of possible values.

SEMIC states that this is possible, but it is better to contact the team of the EU Authority List, and ask them to upgrade their vocab, so we don't need a proprietary vocab.

-> I will do contact the EU Authority List, but dont expect a reaction until our v1.0 publication.

Property "identifier"

We recommend using the property "dct:identifier" as an additional, strong identifier. The RDF URI is the technical identifier, but might not be the best way to clearly identify a dataset.

SEMIC likes our approach of strong identification. However, the alternative property "adms:identifier" should be used. The "dct:identifier" should be identical to the RDF URI, for technical reasons.

-> I will change the property to "adms:identifier" , and refine the usage notes.

7. Property "service category"

We introduced this to link a dataset to a MMTIS service

SEMIC thinks these might cause confusion with "Data Service" (see above), recommends renaming.

-> I will rename to "mobilitydcatap:intentedInformationService".

Updates in recent DCAT-AP 3
https://semiceu.github.io/DCAT-AP/releases/3.0.0/

SEMIC explains among others:

• The ranges of temporal information (for our properties "end date" and "start date") is more generic, using a data type "Termporal Literal", instead of formerly "rdfs:Literal typed as xsd:date or xsd:dateTime"
• The versioning (in context of Dataset Series) is using different namespaces: "dcat:version" instead of "owl:versionInfo"
• Classes "Category" and "Category Scheme" are replaced with more generic Classes "Concept" and "Concept Scheme"

-> I will do the replacements, if I don't see any problems created herewith.

Check examples referenced by the specification

This sentence is added to the spec at the beginning of Section 4. These examples should be updated or removed. Moreover, paths should be relative and not absolute.

Examples on the use of these properties, encoded in [[Turtle](https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#bib-turtle)], are included in the relevant sections. The examples are also available in [[Turtle](https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#bib-turtle)], RDF/XML [[RDF-SYNTAX-GRAMMAR](https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#bib-rdf-syntax-grammar)], and JSON-LD [[JSON-LD11](https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#bib-json-ld11)] from a [separate folder](https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/examples/).

How to publish the "Accompanying Guideline"?

As announced, we are planning an additional document to mobilityDCAT-AP:
the "Accompanying Guideline"!

-> It should be an extra document outside our ReSpec, to be published later this year.

So far, we are collecting inputs and contents on Sharepoint:

I think it's better to make an online version of this, rather than an "oldschool" NAPCORE pdf.
This way, we can update it regularly, publish it at a prominent place, and insert links to external resources (e.g., directing to elements of mobilityDCAT-AP which are explained in the Guideline.)

-> In the end, it will be a mix of text (with (sub-) chapters), FAQs, some figures and references (hyperlinks).
-> Does anyone have an idea how to publish such online version ?
-> I think another ReSpec page is too much!
-> But maybe as a GitHub Pages-Website, which we can host on our regular repository?

Thanks!

Distribution: schema download link and corresponding documentation

For a Distribution, I see the property mobilitydcatap:dataModelSchema. Its description is: “This property describes the schema of the delivered content, as applied for the data model, see property mobilitydcatap:dataModel). The schema can be individually determined by the data provider (e.g., a stakeholder-based DATEX II profile) or a prescribed by other institutions (e.g., a DATEX II recommended reference profile). […]”

I do not quite understand how I have to read this; it reads like “a description of the schema/XSD has to be given in this property”. But XSD in itself is a description.

1. If we take DATEX II as an example, would it not be more, or also, suitable to provide the option to add to a distribution a download link to the schema (XSD)? (Say, maybe dataModelSchemaDownloadURL?)

2. Lots of elaborate documentation about DATEX II profiles (schemas) is given, for example on websites (datex2.eu). If mobilityDCAT-AP would allow to give a link to a schema for download, a property (say, maybe DataModelDocumentationURL) to point to the corresponding documentation for this schema would, in my opinion, be very good to have.

Comments from Maxx Dekkers

Comments received from Maxx Dekkers (SEMIC Group), Email on July 21th, 2023:

Property: Visibility status
Could dct:accessRights not be used here? From the definition of this property at DCMI combined with the use of the EU vocabulary Access right it seems that that Dublin Core property would be able to serve the need.

Property: Data Model Schema
Could dct:conformsTo not be used here? The definition of DCAT includes a usage note for this property that seems to align quite well with the definition of your mobilitydcapap:dataModelSchema.

My general comment here is that if you define ‘local’ properties where you could possibly reuse existing properties, you understand that those data will not be understandable to others outside your domain. So if you share catalogue records with a more general DCAT(-AP) implementation, the access restrictions are no longer maintained. For the distributions the information provided for dataModelSchema will be lost while it could still be useful for the user.

Property: Legal Framework
In the section on Controlled Vocabularies, there is a link to https://eur-lex.europa.eu/eli-register/eu_publications_office.html as the mandatory controlled vocabulary for the property legal framework. However, that link does not point to a controlled set of terms identifying particular legal documents, but points to information on the description schema for legal documents so I think it doesn’t fit there. Maybe the only thing necessary is to add to the usage note of the property that it is recommended to use ELI to refer to legislation whenever possible. By the way, ELI is not only used for European legislation; many countries already use it for national legislation, see https://eur-lex.europa.eu/eli-register/implementation.html.

4. Class: Assessment
   One problem I see here is that you have mappings from two different semantic definitions to the same property (oa:hasBody) – although they really only differ in the expression of the information. First of all, this approach makes it impossible for an application that receives the data to distinguish between them, unless it looks at the encoding. Secondly, there are quite some restrictions on the use of a Literal as value on oa:hasBody. So, no language tag and only plain text allowed. Otherwise you’re encouraged to use oa:TextualBody. So, you could have a single property oa:hasBody with range rdfs:Resource with the usage note that, in case you don’t have a URL to point to, textual information can be included using the Embedded Textual Body construction, which allows you to specify text formats and languages which might be relevant for multilingual purposes.

Suggested changes technical specification

1. Line 45: replace 'Haarmonised' with 'harmonised'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 45 in fe40993

   <p>mobilityDCAT-AP is an extension of the DCAT application profile for data portals in Europe (DCAT-AP) [[DCAT-AP]]. It allows for a structured, interoperable and haarmonised way to describe and exchange metadata about datasets and data services with a mobility relevance. </p>

2. Line 88: replace 'Haarmonised' with 'harmonised'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 88 in fe40993

   <p>This document contains version 1.0 of the specification for mobilityDCAT-AP, an extension of the DCAT application profile for data portals in Europe (DCAT-AP) [[DCAT-AP]]. It allows for a structured, interoperable and haarmonised way to describe and exchange metadata about datasets and data services with a mobility relevance. Its basic use case is to make such datasets and services searchable on data portals with a mobility focus, thereby making mobility information better findable across borders and sectors. </p>

3. Line 101: correct 'wass' to 'was'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 101 in fe40993

   <p>Starting from the analysis of the European recommendations for the interoperability of data catalogues, the Working Group has defined a roadmap for the design, implementation and publication of the metadata schema. The roadmap is composed of five steps: collection of requirements from experts and transportation stakeholders, definition of the conceptual model, implementation, documentation and guidelines, hosting and publication. The conceptual modal, containing definitions of essential metadata elements for mobility data portals, allows for precisely and unambiguously designating a mobility dataset, e.g. for representing the data topic, the data provider or the data format. Further, this model wass linked to established, metadata specifications, namely DCAT-AP. Moreover, a formal metadata specification was elaborated as an extension to DCAT-AP, called mobilityDCAT-AP. </p>

4. Line 143: correct 'refereneced' to 'referenced'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 101 in fe40993

   <p>Starting from the analysis of the European recommendations for the interoperability of data catalogues, the Working Group has defined a roadmap for the design, implementation and publication of the metadata schema. The roadmap is composed of five steps: collection of requirements from experts and transportation stakeholders, definition of the conceptual model, implementation, documentation and guidelines, hosting and publication. The conceptual modal, containing definitions of essential metadata elements for mobility data portals, allows for precisely and unambiguously designating a mobility dataset, e.g. for representing the data topic, the data provider or the data format. Further, this model wass linked to established, metadata specifications, namely DCAT-AP. Moreover, a formal metadata specification was elaborated as an extension to DCAT-AP, called mobilityDCAT-AP. </p>

5. Line 160: remove duplicate sentence: 'In the context of mobility, this might be, e.g., a data collection about static parking information for truck drivers'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 160 in fe40993

   <p>A <strong>Dataset</strong> is a collection of data, published or curated by a single source, and available for access or download in one or more formats. In the context of mobility, this might be, e.g., a data collection about static parking information for truck driversIn the context of mobility, this might be, e.g., a data collection about static parking information for truck drivers, published by a road authority.</p>

6. Line 167: remove duplicate words in bold: 'A Metadata registry is a A Metadata registry'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 167 in fe40993

   <p>A <strong>Metadata registry</strong> is a A Metadata registry is a digital recording of all metadata entries in a data portal, each describing the administration, organisation, and content of individual publications, including the published data set and the corresponding distributions. The most visible Metadata representation are the dataset descriptions in a GUI of a NAP portal.</p>

7. Line 167 (and following): Fix inconsistency in wording: 'data set' but before the term 'dataset' is used. Fix this inconsistency throughout the document (e.g. next occurence on Line 169). Suggestion to use wording 'dataset'.
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 167 in fe40993

   <p>A <strong>Metadata registry</strong> is a A Metadata registry is a digital recording of all metadata entries in a data portal, each describing the administration, organisation, and content of individual publications, including the published data set and the corresponding distributions. The most visible Metadata representation are the dataset descriptions in a GUI of a NAP portal.</p>

8. Line 184: delete comma in 'data portals, e.g., allowing'
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 184 in fe40993

   <p>Such metadata senders and receivers are important actors for interoperable metadata, i.e. whenever there is an exchange of metadata between IT systems. This may happen when there are metadata import and export functions in a data portal. In this case, metadata senders and receivers are other data portals, e.g., allowing harvesting of metadata. So, the following terms refer to the capability of a data portal to provide corresponding metadata in an export function, or to read them in an import function.</p>

9. Line 283: review if naming is correct: 'External assesment' mentioned here while later on only 'Assesment'.
   

   mobilityDCAT-AP/drafts/latest/index.html

   Line 283 in fe40993

   <li>+<a href="#assessment">External assessment</a></li><!-- mobilityDCAT-AP addition-->

10. Line19 (Class assesment): Change & add text in bold 'to set up procedures to assess the compliance of the Delegated Regulations' with 'compliance with the applicable Delegated Regulations'
    

    mobilityDCAT-AP/drafts/latest/tables/class-assessment.html

    Line 19 in 750e089

    <p>An assessment procedure by an external organisation. This organisation MAY be a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance of the Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [[NAPCORE-NB]] and installed individually in each Member State.</p>

@peterlubrich: new as of 25/07/2023 below:

11. Line 52 (Class assesment): suggestion to remove 'draft' from the Optional property 'assesment result'
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-assessment.html

    Line 52 in 3a9b30d

    <p>This property MAY be used to describe the draft result of the latest assessment procedure, in form of a textual description.</p>

12. Line 70 (Class assesment): suggestion to remove 'draft' from the Optional property 'assesment report'
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-assessment.html

    Line 70 in 3a9b30d

    <p>This property MAY be used to describe the draft result of the latest assessment procedure, in form of a URL linking to external details or results.</p>

13. Line 70 (Class assesment): suggestion to remove 'external' from the Optional property 'assesment report' in order to generalise this property (e.g. use by data portals that are not NAPs or for NAPs that publish the report of the NB on the same hostname (website) as the NAP itself.)
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-assessment.html

    Line 70 in 3a9b30d

    <p>This property MAY be used to describe the draft result of the latest assessment procedure, in form of a URL linking to external details or results.</p>

14. Line 54 (Class catalogue - mandatory properties): suggestion to change 'should' by 'could be generated by the system', I do not think this would give good results on a platform with multiple languages (such as BE NAP) where metadata could be entered in a language different from the language of the GUI (e.g. as many users are multilingual and might provide metadata in EN while viewing the webpage in one of their native languages NL, FR or DE)
    

    mobilityDCAT-AP/drafts/latest/tables/mandatory-properties-for-catalogue-record.html

    Line 54 in 9a7be84

    <p>This property refers to a language used in the textual metadata describing titles, descriptions, etc. of the metadata entry. The value should be generated automatically by the NAP system, corresponding to the currently used language in the user interface. Some portals offer multilingual user interfaces, e.g., in the local language and additionally in English. For multiple languages - see <a class="no-secRef" href="#accessibility-and-multilingual-aspects"></a>. A controlled vocabulary <a class="no-sectionRef" href="#controlled-vocabularies-to-be-used"></a> is provided.</p>

15. Line 36: (Optional properties for dataset - Assesment result): suggestion to rephrase 'he property SHOULD point to the recent assessment procedure' to 'he property SHOULD point to the most recent assessment procedure' (addition in bold)
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-dataset.html

    Line 36 in 3fd5bb7

    <p>The property SHOULD point to the recent assessment procedure, including its date, its result as a free-text and/or a link referring to an assessment report online.</p>

16. Line 141: (Optional properties for dataset - identifier): Suggestion to change to mandatory (conform the conceptual model). A unique identifier for the dataset is essential for harvesting purposes. Please review why this was changed to an optional property.
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-dataset.html

    Line 141 in 3fd5bb7

    <tr class="property optional" id="dataset-identifier">

17. Line 38: Mandatory properties for Distribution: accessURL: review cardinality '1..n' not conform with conceptual model: only one accessURL for a distribution (if not it should be a seperate distribution for the dataset). Suggestion to change to '1..1'
    

    mobilityDCAT-AP/drafts/latest/tables/mandatory-properties-for-distribution.html

    Line 38 in 3fd5bb7

    <p>1..n</p>

18. Line73: Mandatory properties for Distribution: format: spelling mistake in sentence 'There reason is the use'. Please correct 'There'.
    

    mobilityDCAT-AP/drafts/latest/tables/mandatory-properties-for-distribution.html

    Line 73 in 3fd5bb7

    <p>There is a similar property in [[DCAT-AP-v2.0.1]] <code>dcat:mediaType</code>, which is removed in mobilityDCAT-AP. There reason is the use of Controlled vocabularies: <code>dct:format</code> uses the EU Authority List [[EUV-FT]], whereas <code>dcat:mediaType</code> uses the IANA media types [[IANA-MEDIA-TYPES]]. The first one, however, is sufficient to describe the syntaxes commonly used in mobility data portals. </p>

19. Line 73: Recommended properties for Distribution: The example shown 'e.g., DATEX II v3.2.' does not specify whether the full format (which would be mandatory property dct:format for the Distribution) plus the version number should be mentioned (in the example: DATEX II v3.2), or only the version number (in the example: (v)3.2). Please clarify this
    

    mobilityDCAT-AP/drafts/latest/tables/recommended-properties-for-distribution.html

    Line 73 in 3fd5bb7

    <p>This property describes the version of the Grammar, Schema, or Data Model of the delivered content within the Distribution (see the corresponding properties). A version might be, e.g., DATEX II v3.2. This information should be provided in a textual format. </p>

20. Line 137 (and below): Optional properties for distribution: data format notes: missing range definition. Suggestion to add 'rdfs:Literal'.
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-distribution.html

    Line 137 in 3fd5bb7

    <p>+data format notes</p>

21. Line 186: Optional properties for distribution: DowloadURL cardinality '0..n' not conform conceptual model '0..1'. Please review/change.
    

    mobilityDCAT-AP/drafts/latest/tables/optional-properties-for-distribution.html

    Line 186 in 3fd5bb7

    <p>0..n</p>

"rights holder" comment says this is contact point for questions about the data set, not correct in all cases

In the comments about rights holder, the sentence "This entity is the direct contact for the platform operator or data consumers, who have questions or issues about the contents of a dataset." does not fit the reality for many datasets. For instance a dataset of all public transport timetables in a country, where each transport operator will be listed as a rights holder, but the dataset is maintained by a national entity who will be the preferred contact point for questions about the dataset.

+rights holder
dct:rightsHolder
foaf:Agent
This property refers to an entity that legally owns or holds the rights of the data provided in a dataset. This entity is legally responsible for the content of the data. It is also responsible for any statements about the data quality (if applicable, see property dqv:hasQualityAnnotation) and/or the relevance to legal frameworks (if applicable, see property dcatap:applicableLegislation).

This entity is the direct contact for the platform operator or data consumers, who have questions or issues about the contents of a dataset.

Images not showing in HTML documentation

When I open the documentation (index.html), the images do not load correctly.

The images are located in a subfolder (mobilityDCAT-AP/releases/figures) while the index.html is contained in a folder above (mobilityDCAT-AP/releases/1.0.X)

To solve the issue, the figures folder could be copied into the folder of the different releases, or the reference in the release could be made to ../figures/[imagelocation].

Remove unused files from GeoDCAT-AP

Remove unused files from GeoDCAT-AP, e.g., https://github.com/mobilityDCAT-AP/mobilityDCAT-AP/blob/gh-pages/drafts/latest/appendices/inspire-and-iso-19115-mappings.html

Download of SHACL (Turtle) file fails

On this page I can click on a download link for a SHACL (Turtle) file. However, clicking the link results a 404 Page not found. Can this be fixed?

Sorting of references

The references appear under:

• Section D.1 normative references
• https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#normative-references

and:

• Section D.2 informative references
• https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/#informative-references

There were coded within this file:
https://github.com/mobilityDCAT-AP/mobilityDCAT-AP/blob/gh-pages/drafts/latest/config.js
..under "localBiblio:", starting in line 188

-> However, I dont know how ReSpec is sorting the entries under "localBiblio:" into sections D.1 and D.2.
-> The sorting seems arbitrary.
-> Does anyone know?

Thanks

Typos to be fixed

List here typos to be fixed for the next release

SHACL shapes how-to

Early adopters would like to have a dedicated paragraph in the Wiki explaining how to validate mobilityDCAT-AP metadata against the SHACL Shapes. @lcomet maybe you can suggest/explain the tool you used for the examples?

Recommended properties for catalogue: LinguisticSystem: Review cardinality

Recommended properties for catalogue: LinguisticSystem: Review cardinality: 0..n not conform with Excel conceptual model (1..n)

mobilityDCAT-AP/drafts/latest/tables/recommended-properties-for-catalogue.html

Line 38 in 152af3b

<p>0..n</p>

Referencing to data categories from EC Delegated Regulations

We plan to reference all “categories” & “sub categories” (from our Controlled Vocabulary Mobility Theme (mobilitydcat-ap.github.io) to the corresponding data categories from EC Regulations.

Reason: see Wikipage, section 3.2.

There will be an additional entry under each “category” & “sub category” in our Controlled Vocabulary.
We will use the property “dcatap:applicableLegislation” for that addition.
This will be done in a future version of the Controlled Vocabulary.

By the way: there was already a referencing to the EC Regulations for the Coordinated Metadata Catalogue:
https://www.its-platform.eu/wp-content/uploads/ITS-Platform/AchievementsDocuments/NAP/EU%20EIP_Coord.%20Metadata%20Catalogue_Annex%20I_v2.0_191115.xlsx

We need volunteers to re-do such referencing in the Controlled Vocabulary "Mobility Theme".

SHACL shapes and controlled vocabularies

The mobilityDCAT-AP SHACL shape seems to contain a reference to not existing controlled vocabularies

mobilityDCAT-AP/drafts/1.0.1-draft-0.1/mobilitydcatap_shacl_shapes_v1.0.0.ttl

Line 607 in c7249d8

# Concepts from controlled vocabularies defined and used in mobilityDCAT-AP.

like https://w3id.org/mobilitydcat-ap/data-content-category and https://w3id.org/mobilitydcat-ap/service-category.

I think this is an oversight due to the previous naming of the vocabularies. It does not seem to me that these vocabularies are referenced in the ReSpec page. The updated list of vocabularies is documented here.

1.0.0 repository: examples directory can be deleted?

Seems there is a folder in the 1.0.0 directory that can be deleted:
see: "releases/1.0.0/examples"

Seems the files in this folder are still copies from the geoDCAT-AP repository (which we used as a baseline).
In 1.0.0, we didn't use any examples.
Suggestion: delete the entire example folder.

In 1.0.1., we will publish some example files, which will be saved in this future folder: "releases/1.0.1/examples

Property Legal Framework does not exist GitHub

The property Legal Framework does not exist in the repository

Reorganize and fix URLs to resolve content

Consider the draft and published versions only.
https://w3id.org/mobilitydcat-ap/releases/ and https://w3id.org/mobilitydcat-ap/releases/1.0/ should be resolved accordingly.
Once the identifier "mobilitydcat-ap" under w3id is available:

1. Fix the URL from https://mobilitydcat-ap.github.io/mobilityDCAT-AP/drafts/latest/ to https://w3id.org/mobilitydcat-ap/drafts/latest/ in the Readme file.
2. Check the redirecting of the URLs

Controlled vocab for Property "frequency": missing values in EU Authority List

We link this to a Controlled Vocab from the EU Authority List. Because this vocab is missing some values that we need, we added another proprietary vocab. Both vocabs together provide the entire list of possible values.

SEMIC states that this is possible, but it is better to contact the team of the EU Authority List, and ask them to upgrade their vocab, so we don't need a proprietary vocab.

-> We need to contact the EU Authority List, but only after our v1.0 publication.

Data format version

The data format version (mobilitydcatap:dataFormatVersion) is modelled as a rdfs:Literal. In the example it is filled with "DATEX II v3.2". Using Literal may make it difficult to filter the values entered by the various member states, because it also can be filled with, for example "DATEX-II-v3.2" or "DATEXIIv3.2" or even different values.

To overcome this isse, it may be an idea to use a controlled vacabulary for the data format version.

For example the EU Vocabularies include a controlled vocabulary for File type.

A solution option could be to add, for example, DATEX_II_v3_XML and DATEXII_v2_3_XML and other for mobilityDCAT-AP needed filetypes to the File type defined in the EU vocabularies controlled vocabulary and use the SKOS concept instead of the Literal.

Of course, a precondition is that the EU vocabulary for filetype is actively managed and can be adapted quickly enough if filetypes need to be added for mobilityDCAT-AP. Otherwise, maybe an mobilityDCAT-AP controlled vocabulary may be used.

Change description of the mobilityDCAT-AP repository and organisation

To be changed:

• Add README to the organisation with link to the specification and relevant documents
• Specify it is not only for NAPs
• Change the link in the repo now pointing to NAPCORE news?

Catalog class: no service proprerty

Dear

I noticed in your mobilityDCAT-AP profile there are no service proprety in the Catalog object type. This property is to be used in order to specify or to document any Data Service in the considered Catalog.

I think this is a very surprising position as that property is "Recommended" in the current version of DCAT AP 3 (https://semiceu.github.io/DCAT-AP/releases/3.0.0/#quick-reference) and Service object type is explicitly specified in mobilityDCAT AP.

Therefore I strongly recommend to define the service proprety in this profile in order to reference any Data Service in the meaning of DCAT standards.

Regards,

Catch up with updates in recent DCAT-AP v3

Updates in recent DCAT-AP 3
https://semiceu.github.io/DCAT-AP/releases/3.0.0/

SEMIC highlights some changes, that might be also considered by mobilityDCAT-AP:

1. The ranges of temporal information (for our properties "end date" and "start date") is more generic, using a data type "Termporal Literal", instead of formerly "rdfs:Literal typed as xsd:date or xsd:dateTime"
2. The versioning (in context of Dataset Series) is using different namespaces: "dcat:version" instead of "owl:versionInfo"
3. Classes "Category" and "Category Scheme" are replaced with more generic Classes "Concept" and "Concept Scheme"

-> We can do the replacements, after a detailed analysis of DCAT-AP v3.
-> To be considered in future version of mobilityDCAT-AP.