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

dct:source is not specific enough #4

Open
letmaik opened this issue Jan 31, 2016 · 1 comment
Open

dct:source is not specific enough #4

letmaik opened this issue Jan 31, 2016 · 1 comment

Comments

@letmaik
Copy link
Contributor

letmaik commented Jan 31, 2016

Currently dct:source is used with multiple aliases within JSON-LD in the spec:

  • subsetOf (section 8 & 9), both for single coverages and also collections
  • filteredFrom (section 7), referring to the unfiltered collection

A more general alias would be derivedFrom (if one doesn't like the word source itself).

dct:source is defined as:

A related resource from which the described resource is derived. The described resource may be derived from the related resource in whole or in part.

The main problem is that dct:source is not specific enough in our context. However, defining more specific terms that are still suitable for general use is hard.

I see especially problems with subsetOf since the term "subset" is defined differently in different domains or contexts. For example, if a coverage suits itself for representation as a collection of measurements, then a "subset" is just equal to filtering the collection. And the question arises: what is a subset really?

filteredFrom on the other hand seems to have more or less clear semantics. If A is a collection that is filtered using some criteria and the resulting filtered collection is B, then B filteredFrom A. This term is also relevant within the Hydra WG.

Another issue is that sometimes you want to know how exactly a collection got filtered or a coverage subsetted. That could mean including the filtering/subsetting parameters that were used in a URL template for example. This is equivalent to having form inputs (categories, search term) etc. filled in after searching on a website like Amazon. This seems also relevant for the Hydra WG.

Any suggestions welcome.

@letmaik
Copy link
Contributor Author

letmaik commented Feb 4, 2016

Check how PROV can be used here. See related thread in hydra-public about collection filtering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant