Add support for DCAT catalog navigation
In the dataspace ecosystem, the vocabulary used to describe and register available datasets from a data provider are based on DCAT which is a vocabulary for defining catalogs/data/datasets/etc.
We need to add native support of DCAT catalogs as we do with LDP Containers for our framework to be used efficiently in our customer or research projects which are already based on the connectors implementations like the EDC, as those implementations are exposing their catalogs of resources using DCAT.
On the backend side, we should also switch or complement djangoldp containers support with DCAT-based catalog serialization, would make more sense.
Example of a list of cloud services formatted as a DCAT Catalog (from chatGPT):
{
"@context": "https://www.w3.org/ns/dcat#",
"@type": "Catalog",
"@id": "https://cloud-provider.example.com/catalog",
"title": "Cloud Services Catalog",
"description": "A catalog of cloud services offered by Example Cloud Provider.",
"publisher": {
"@type": "Organization",
"name": "Example Cloud Provider",
"url": "https://cloud-provider.example.com"
},
"dataset": [
{
"@type": "Dataset",
"@id": "https://cloud-provider.example.com/catalog/compute",
"title": "Compute Services",
"description": "Virtual machines, containers, and serverless computing services.",
"keyword": ["compute", "virtual machines", "serverless"],
"theme": "https://www.example.com/themes/cloud/compute",
"contactPoint": {
"@type": "ContactPoint",
"fn": "Support Team",
"hasEmail": "mailto:support@cloud-provider.example.com"
},
"distribution": [
{
"@type": "Distribution",
"title": "Compute API",
"accessURL": "https://api.cloud-provider.example.com/compute",
"format": "API"
}
]
},
{
"@type": "Dataset",
"@id": "https://cloud-provider.example.com/catalog/storage",
"title": "Storage Services",
"description": "Block storage, object storage, and archival storage solutions.",
"keyword": ["storage", "block storage", "object storage"],
"theme": "https://www.example.com/themes/cloud/storage",
"contactPoint": {
"@type": "ContactPoint",
"fn": "Storage Support Team",
"hasEmail": "mailto:storage-support@cloud-provider.example.com"
},
"distribution": [
{
"@type": "Distribution",
"title": "Storage API",
"accessURL": "https://api.cloud-provider.example.com/storage",
"format": "API"
}
]
},
{
"@type": "Dataset",
"@id": "https://cloud-provider.example.com/catalog/networking",
"title": "Networking Services",
"description": "Virtual networks, load balancers, and VPNs.",
"keyword": ["networking", "load balancing", "VPN"],
"theme": "https://www.example.com/themes/cloud/networking",
"contactPoint": {
"@type": "ContactPoint",
"fn": "Networking Support Team",
"hasEmail": "mailto:networking-support@cloud-provider.example.com"
},
"distribution": [
{
"@type": "Distribution",
"title": "Networking API",
"accessURL": "https://api.cloud-provider.example.com/networking",
"format": "API"
}
]
}
]
}
So this DCAT:Catalog should be dereferenced as a list, as are the LDP:Container in our store.
We can see in the current codebase that we consider a property of a resource to be a list when a call on isContainer(resource) returs true (check all references to isContainer in the code for instance).
This isContainer() method checks the @type of a resource and compare it to a static list:
this.containerTypes = [
this.getExpandedPredicate('ldp:Container'),
this.getExpandedPredicate('ldp:BasicContainer'),
this.getExpandedPredicate('ldp:DirectContainer'),
this.getExpandedPredicate('ldp:IndirectContainer'),
this.getExpandedPredicate('sib:federatedContainer'),
];
We should implement a similar mechanism to handle DCAT Catalogs.