Comments from Maxx Dekkers

[peterlubrich]

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.

[peterlubrich]

Regarding 1:

Petr Bures:
adopt the suggestion

Hilde/Peter Lubrich:
do not use dct:accessRights because we dont expose the metadata externally, if our property "visibility" is set to "false"!
In contrast, the proposed EU Controlled Vocab is implying some exposing of meta data in any case, but controlling the access to content data. So, dct:accessRights is not the right replacement here!

Peter Lubrich:
I tried to clarify the above argument as a usage note, see Respec! But there are still confusions with "dct:accessRights" so we need to clear this up!
The conceptual Model (by Benjamin) introduced "visibility" to set a flag inside the NAP system, telling that a metadata entry is publishable or not. Only metadata entries with a "visibility" = "True" will be exchanged externally.
On the other side, mobility DCAT-AP is about exchanging metadata. So, cases with "visibility" = "False" are out of scope of mobilityDCAT-AP!

Suggestions:

1. Remove our property "mobilitydcatap:visibilityStatus"
2. Make a comment in the "Accompanying Guideline" that fields like "visibility" are NAP-internal metadata fields, that are not exchanged externally. These are not defined by mobilityDCAT-AP, but can be instead established by a NAP individually.

[peterlubrich]

Regarding 2:

Peter Lubrich:
In fact, "dct:conformsTo" might be used "to indicate the model, schema, ontology, view or profile that this representation of a dataset conforms to".
However, we introduced multiple properties under the class Distribution, that describe the technical format:

• format dct:format
• data model mobilitydcatap:dataModel
• data model version mobilitydcatap:dataModelVersion
• data model schema mobilitydcatap:dataModelSchema
• grammar mobilitydcatap:grammar

-> Such differentiation is very specific to the transportation domain, and we want to have such clear differentiation !
-> We could now replace each of our proprietary properties above ("mobilitydcat-ap:...") with "dct:conformsTo".
-> But then we would lose our intended differentiation !
-> On the other side, Maxx is right, any information from our proprietary properties might get lost when exchanging metadata with non-transportation portals!

Your opinions?

[peterlubrich]

Regarding 3:

Peter Lubrich:
The question here is: Is the ELI system a controlled vocabulary or not?
Either way, we want to have it used for our property "mobilitydcatap:legalFramework".

Suggestion:

1. Add a hint in the usage note next to the property, linking to ELI, as suggested by Maxx.
2. Still list the ELI in our section "Controlled vocabularies to be used", (so it doesn't get ignored), but also mention here that this is not a real Controlled Vocab!

[BWitsch]

Regarding the "visibilty status":
The idea behind was that data describtions could be unfinished, on hold or in generak not published.
For statistics on data set this field has a hugh benefit for the NAPs.
For operating the API for data exchange this is the filter to destinguish "sendable" or not.
But it is not necessary to be in the DCAT-AP Profile if obly published data descritions are exchanged.

[BWitsch]

Regarding 2 Data format "dct:conformsTo"
The information around the data format, encoding, used schema and so on are very important for data user and data services!!
Therefore we should have this differentiation.
If we exchange meta data with other portals, it is up to the harvesting portal how they handle the more information.

[peterlubrich]

Regarding 4:

I agree with Maxx' suggestion: we will only use one single property oa:hasBody, and make an additional usage note about (optional)textual information

[peterlubrich]

Regarding 1:

I responded to Maxx as follows:

"Well, when you look closely at the EU vocabulary for "Access right", it seems to controll the access to content data, whereas the meta data is exchanged in any case. In contrast, we wanted to controll the access/visibility of meta data. So, "Access right" seems not to be the right replacement for our proposed property.

However, the only options for our property are "true" (=metadata is exchanged) or "false" (=metadata is not exchanged). The latter one is not relevant, as this metadata stays (temporarily) within the data platform. In thise sense, the "metadata visibility" is not a information to be exchanged, but more a platform-internal information. So, well will give up the "Visibility status" for now.
We may re-introduce it at a later time, as they are some use cases with "limited" or "restricted" metadata visibility (in transportation, many (meta)data is considered non-open!). This means that only selected receivers can see the metadata, or that some receivers can only see partial metadata. We will discuss this later."

[peterlubrich]

Regarding 1:

We got a response by Makx as follows:
I understand you want to look at this later. As this information is not going to be exchanged but rather used for the data platform itself, it could indeed be considered at a later stage. However, contrary to what you wrote, the CatalogRecord gives information about the metadata, so asserting dct:accessRights on CatalogRecord will give the visibility of the metadata, not of the content. To describe the visibility of the content, you would use the property dct:accessRights on dcat:Dataset.

->Conlusion: for mobilityDCAT-AP v1.0, the proposal is to take out the "visibility status" property. We might consider this again for v2.0, when we have a clearer picture about use cases of restricted metadata visibility.

[peterlubrich]

Regarding 2:

We got a response by Makx as follows:
Making these properties subproperties of dct:conformsTo indeed allows other DCAT implementations to understand what the general meaning of these properties is, so this makes sense. One additional comment is that, if we understand correctly, the dataModelVersion and dataModelSchema properties describe characteristics of the data model and not of the distribution, so it would be more correct to define those as properties of a separate entity, for example a class mobilitydcatap:DataModel, which could be a subclass of dct:Standard.

->Conlusion: I really like the proposal to introduce a new class "mobilitydcatap:DataModel".
This class will be the range of property "mobilitydcatap:dataModel" (so far, it has the generic range "skos:Concept").
This class will be a sub-class of class "dct:Standard".
This class have two optional properties:

1. "owl:versionInfo" (formerly proposed as proprietary property "mobilitydcatap:dataModelVersion")
2. "mobilitydcatap:dataModelSchema" (as sub-property of "dct:conformsTo")

[peterlubrich]

Regarding 3:

We got a response by Makx as follows:
In the work on High-Value Datasets, a property dcatap:applicableLegislation (applied to the DCATAP HVD extension here) was defined that has the same meaning as your property mobilitydcatap:legalFramework. You could use the more general property from the dcatap namespace.

->Conlusion: we change the property from "mobilitydcatap:legalFramework" to "dcatap:applicableLegislation"

[peterlubrich]

My conclusion for topics 1,2,3 above would also result in a modified UML diagram as follows.
For example, note the new class "mobilitydcatap:dataModel" in the upper-right corner.

[peterlubrich]

I took over all proposals under "conclusions" above for point 1,2,3,4.