Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ID25 to be revised #9

Open
kcoyle opened this issue Jul 18, 2017 · 9 comments

Comments

@kcoyle
Copy link
Contributor

commented Jul 18, 2017

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

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

@agbeltran agbeltran added the ucr label Jul 23, 2017

@jpullmann jpullmann self-assigned this Jul 24, 2017

@agbeltran agbeltran added the use case label Sep 11, 2017

@jpullmann

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 4, 2019

+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

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 19, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.