ID25 to be revised

[kcoyle]

Conclusion at F2F (July 17, 2017) - revise and resubmit.

See minutes: https://www.w3.org/2017/07/17-dxwg-minutes

[jpullmann]

There was a controversial discussion on topic of restricting copies of Catalog metadata. Action on me to edit and align with Makx, Action 02, yet to be done. Sadly, there is no concrete criticism, some of us simply considered ID25 out of scope. My rationale was: catalog metadata is precious, policies like "you may not copy", "you may copy, but keep in synch", or "you may copy, but attribute my work" make sense to me. @makxdekkers - could you please have a look and suggest updates, e.g. including more examples?

[makxdekkers]

@jpullmann My opinion was that in some environments the attachment of licences and rights to metadata, e.g restricting copying, correcting, enriching, is considered to be problematic. Even attribution of the metadata could seriously affect re-use. A main issue is that, in RDF, 'metadata' is not a singular thing as it consists of a set of 'statements' (subject predicate object). So, to be able to satisfy any licensing arrangement, one might need to keep track of provenance and licence information for each and every statement. The case of "you may not copy" is easy: that's probably a catalogue-wide restriction and a harvester will just go away and not include anything from the catalogue at hand. Other types of licences are more problematic. Let's imagine a situation that a harvester copies a set of statements from a source and then adds some statements that reflect an interest from its audience, e.g. additional subjects, or automatic translations of textual information. In case of a "keep in sync" licence, does the original source really want all of the new fields added by the second source to be copied back? How do these changes get transmitted? Does the original source now need to attribute the additional statements to the second source? Another situation could occur with "attribution" licences in chained harvesting, e.g. a regional catalogue harvested by a domain-specific aggregator which is then harvested by a general aggregator -- a situation that occurs in the European DCAT-AP network -- where each aggregator adds some fields. This gets complicated very quickly: what is attributed to whom?
In summary, while it would be simple to add dct:license to dcat:CatalogRecord, I think the operational consequences are difficult to describe.
On the other hand, I know that Europeana suggests an interesting mix of CC0 for metadata plus attribution, CC0+BY (here and also here), so maybe @aisaac can shed some light on the practical issues around this?

[kcoyle]

+1 to Makx. We had this very situation in the library world where a major source of data (that got copied into library catalogs world-wide) tried to impose a license. Not only was it offensive to the community, it was actually illogical because it could not be even defined much less enforced. Anything less than CC0 is a detriment to use and reuse.

[jpullmann]

@makxdekkers I see your point, normally it would not be individual meta-data instances but the entire catalog of interest to harvesters. In this case the policies are covered by dcat:Catalog/dct:rights or a dct:licence reference. The UC was reflecting talks to industrial partners that were interested in a role of data broker (by means of curated, valuable metadata), where the catalog or individual resource metadata may be considered a policy target.
@kcoyle how to proceed with the UC? It still seems valid to care about (conditions of) reusing DCAT meta-data, but it will not be tackled anew by the group ("wan't fix"), since a solution on catalog-level exists?

[kcoyle]

Does this bring anything new to what DCAT has defined? If not, then this can be considered resolved by dcat:license, dcat:rights, and dcat:hasPolicy.

[makxdekkers]

In my opinion, there is no need for changes to DCAT. @kcoyle: there is no property dcat:hasPolicy; the current draft recommends to use odrl:hasPolicy "in the particular case when rights are expressed via ODRL policies".

[kcoyle]

Thanks, Makx. I was reading from the DCAT outline which names the properties without prefixes

Property: hasPolicy

Obviously I should have looked further.

I also do not see the need for any changes and suggest that this be closed.

[jpullmann]

Coming back to the issue - I'd suggest to close it, o.k.? The discussion here does not invalidate the use case (problem space) while it points to solutions already available.

[kcoyle]

Yes, it appears to be the case. I'll mark it for closure and confer with Peter.