Interoperable Europe logo

How to express metadata license?

Anonymous (not verified)
Published on: 26/03/2015 Discussion Archived

In some cases the license of the metadata could be different from the license of the dataset itself. How can this be expressed in DCAT-AP?

 

Related may be other properties that applies only to the metadata, e.g. dct:conformsTo - dcat

 

Cheers

Component

Documentation

Category

improvement
Report abusive content Invite Share

Comments

Makx DEKKERS
Makx DEKKERS Sat, 28/03/2015 - 08:28

An option to express the licence for the metadata of the Dataset is the use of dct:license on the CatalogRecord.

On the second statement: the subject of the conformsTo predicate is the Dataset, not the metadata about the Dataset. 

 

Anonymous (not verified) Fri, 17/04/2015 - 15:09

I agree with Makx. You can already specify the metadata for the catalog. (Although I guess there is the semantic confusion that the records in the dcat:catalog do not inherit properties, and on a legal point maybe we should be explicit.)

 

The remaining question is whether any catalogs have more than one metadata licence. I can think of no existing examples. At data.gov.uk it is a condition of any metadata coming in that it is made available under our standard licence, if not already.

 

However there is more and more talk of metadata being spread-around portals in a web. I guess the pan-European portal will be an example of this, and may benefit from recording the metadata licence of records, inherited from their source catalog. In this case, perhaps we can add dct:license as an optional property of dcat:CatalogRecord?

Hans OVERBEEK
Hans OVERBEEK Tue, 28/04/2015 - 16:28
Will a metadata broker pass metadata about source Catalogs and Catalog Records, or replace it by metadata about it's own Catalog and Records?   Example: The national dataportal in the Netherlands (DONL) harvests metadata from different data Catalogs like the National Geo Register (NGR). Then DONL provides metadata to the EU dataportal using DCAT-AP. So DONL is a metadata broker.   NGR --> DONL --> EU dataportal   Source catalog --> Metadata Broker --> Target Catalog   DONL keeps a list of (Source) Catalogs. And the Catalog Records in DONL describe the records in the Source Catalogs. From the perspective of the Target Catalog (EU dataportal), the metadata broker DONL is a Catalog in itself. So when DONL provides metadata to the EU dataportal, will it describe the Catalog Records in the Source Catalogs or will it describe it's own records?    By the way: DONL itself is just one of the Catalogs: A provider of a Dataset can manually enter metadata about that Dataset directly into DONL. In that case the Catalog is DONL.   The answer to the question has implications for the issue about licence and language of Catalog and Catalog Records. I think a broker should should pass the metadata about the Source Catalogs and not replace it by it's own. Then it would be sufficient to keep licence and language of the Source Catalog, and we don't have to keep licence and language of each Catalog Record.   The reason I ask is that the DCAT-AP, as well as DCAT at W3C, seem to focus on Source Catalogs and not on metadata brokers that provide a Catalog in itself. See for intstance the Conformance section of DCAT [1]. It says "A data catalog conforms to DCAT if: (...) An RDF description of the catalog itself and its datasets and distributions is available (...)". This does not anticipate other Catalogs.   [1] http://www.w3.org/TR/vocab-dcat/#conformance.
Makx DEKKERS
Makx DEKKERS Thu, 30/04/2015 - 11:41

Hans, very good points. DCAT is indeed designed for the simple model that a catalogue exposes the metadata of its own datasets, and does not consider (chaining of) metadata aggregators. For this round of revision of the specification, this issue is out of scope but I agree that there is a need to analyse various operational models to come up with 'best practices' and sensible advice.

 

A feature of the open world paradigm is that metadata of datasets can be changed along the chain, e.g. through enrichment, error correction, translation etc., so it might not aways be clear what part of the metadata was generated where. Pointing back to the location of the original metadata at least gives the information where it came from but even that original metadata could be updated after it has been harvested. Things may get complicated, but in a future activity we might be able to extract a number of typical cases for which recommendation could be given.

Makx DEKKERS
Makx DEKKERS Sun, 21/06/2015 - 13:29

The working group agreed in its meeting of 10 June 2015 not to add this functionality to the Application Profile.

Login or create an account to comment.