Comments from Maxx Dekkers

[mobilitydcat-ap]

Comments from Maxx Dekkers

[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.