Incorrect use of the dct:conformsTo property? (+Possible solution)

[basharmsen]

Hello,

I think I have found a problem in the FAIR Data Point specifications and I have a possible solution. This is the problem (It's quite a long story, but that's because the problem is also quite complex.):

An HTTP request to a FAIR data point for a Catalog, Dataset, Distribution etc. returns RDF data containing triples describing the resource. Since the data returned for the URL is not the resource itself but its description, I think the statement <https://fdp.example.org/distribution/[GUID]> a dcat:Distribution . for example is not correct. To solve this problem, one can distinguish between the resource and its description by using a hash URI or a 303 URI (see: link). So for example <https://fdp.example.org/distribution/[GUID]#this> for a Distribution resource and <https://fdp.example.org/distribution/[GUID]> for its description. This will make the statement <https://fdp.example.org/distribution/[GUID]#this> a dcat:Distribution .. Since the profile returned when accessing https://fdp.example.org/profile/[GUID] describes the RDF graph returned when accessing https://fdp.example.org/distribution/[GUID], the statement <https://fdp.example.org/distribution/[GUID]> dcterms:conformsTo <https://fdp.example.org/profile/[GUID]> . does seem correct to me.

I ran into this problem when I was trying to specify the structure of a Distribution more precisely (for example, by specifying a JSON schema for a JSON resource). The dct:conforms property seems to be the right property for this purpose, but I noticed it was already used for the profiles. After reading the DCAT standard, the use of dct:conforms in DCAT remained rather unclear to me. I found a discussion on this topic in the DCAT GitHub-repository of the W3C Dataset Exchange Working Group (w3c/dxwg#1130) that clarified this for me. The dct:conforms property of a dcat:CatalogRecord instance seems to be the way to specify the profile. One issue I see is that the value of foaf:primaryTopic for a dcat:CatalogRecord instance is by definition a dcat:Resource and this seems to be a problem because for example a dcat:Distribution doesn't need to be a dcat:Resource. Also, I'm not sure if a dcat:CatalogRecord is a Web document. (So can the URI <https://fdp.example.org/distribution/[GUID]> point to an instance of dcat:CatalogRecord?). I think both issues don't need to be a real problem and it makes sense to write:

<https://fdp.example.org/distribution/[GUID]#this>
  a dcat:Distribution;
  dct:title "sample-distribution";
  dct:mediaType "application/json";
  dct:conformsTo [
    rdfs:label "a JSON schema"
  ] .

<https://fdp.example.org/distribution/[GUID]>
  dct:conformsTo <https://fdp.example.org/profile/[GUID]>;
  foaf:primaryTopic <https://fdp.example.org/distribution/[GUID]#this> .

I'm curious about your thoughts on this.

Regards,

Bas Harmsen

PS A while ago I created an issue for this in the FAIRDataPoint-Spec repository (FAIRDataTeam/FAIRDataPoint-Spec#20) but later I noticed that https://specs.fairdatapoint.org/ points to this repository instead. In addition, I have described the issue in more detail.

[luizbonino]

Hi Bas, thank for reaching out. This issue bothered me since we started the development of the FDP, some 6 years ago. My issue was that it was not clear to me whether the DCAT class represent the "thing" or the metadata record of the "thing". If it would be the "thing", then where can we have some properties of the metadata record? E.g., a dataset may have been created by John but the metadata record of that dataset may have been created by Mary. To address that in a very quick and dirty way we have predicates like metadataIssued, metadataModified, etc. But I was never happy with this solution as they mix properties of two different entities in the same block.

Recently, as I was writing a paper describing the current status of the FDP this issue came back to my mind and I felt the need to solve it. I already discussed the solution with the team and we will add to the upcoming Sprint. In summary we will assume that the DCAT classes refer to the target object and we create another type of class named MetadataRecord that points to the object using the predicate isMetadataOf (as per FAIR principle F3). In this way the class MetadataRecord contains the properties of the metadata record of the object such as the author, date of creation, data of last modification, etc. while the properties of the object (e.g., dcat:Catalog, dcat:Dataset or any sub-class of cat:Resource) are expressed in the object block, under its own identifier. Something like:

<metadataRecordIdentifier> a fdp-o:MetadataRecord;
	fdp-o:isMetadataOf fdp:app;
	dct:description "This is the metadata record of the my dataset."@en;
	dct:license <http://rdflicense.appspot.com/rdflicense/cc-by-nc-nd3.0>;
	dct:identifier fdp:app/metadatarecord;
	dct:issued "2022-02-15T09:09:40.929Z"^^xsd:dateTime;
	dct:modified "2022-02-15T09:09:40.929Z"^^xsd:dateTime ;
	dct:conformsTo <MetadataRecordProfileURI> .

<datasetIdentifier> a dcat:Dataset;
	fdp-o:hasMetadata <metadataRecordIdentifier> ;
	dct:title "My dataset"@en;
	dct:description "My test dataset."@en;
	dct:language <http://id.loc.gov/vocabulary/iso639-1/en>;
	dct:license <http://rdflicense.appspot.com/rdflicense/cc-by-nc-nd4.0>;
        dct:conformsTo <DatasetProfileURI>.

Regarding the conformsTo, we have contacted the DCAT editors on how to properly use it. They instructed us that the conformsTo predicate should point to a profile and, in that profile we can point to, for instance, a schema. Since our intention in the FDP is to have every metadata record to inform which schema it conforms to for, among other reasons, validation, we inform in the profile that the schema (in SHACL) is used with the validation role.