You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently
dct:source
is used with multiple aliases within JSON-LD in the spec:subsetOf
(section 8 & 9), both for single coverages and also collectionsfilteredFrom
(section 7), referring to the unfiltered collectionA more general alias would be
derivedFrom
(if one doesn't like the wordsource
itself).dct:source
is defined as: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, thenB 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.
The text was updated successfully, but these errors were encountered: