Skip to content

Add source_for relation type for forward provenance - #38

Merged
m-mohr merged 2 commits into
mainfrom
forward-provenance-relation-type
Oct 9, 2026
Merged

m-mohr merged 2 commits into
mainfrom
forward-provenance-relation-type

Conversation

@emmanuelmathot

Copy link
Copy Markdown
Member

Introduce the source_for relation type to support forward provenance, allowing a source item to link to derived items. This addition enhances the documentation and changelog to reflect the new relation type, which is the inverse of derived_from.

Fixes #27

@emmanuelmathot
emmanuelmathot requested a review from m-mohr April 29, 2026 06:48
@m-mohr

m-mohr commented Apr 29, 2026

Copy link
Copy Markdown
Contributor

Generally a good idea, I'm just trying to remember whether I have seen this before (which I think) and whether it was using a different relation type. Trying to find it again, maybe worth checking with OGC (Provenance?) as well.

(Side note: It's a bit of a pity that we use _ here and in derived_from while in (all?) other relations we use -)

@emmanuelmathot

Copy link
Copy Markdown
Member Author

I checked OGC: the OGC link relation register and IANA have no forward-provenance relation. OGC Testbed 20 (24-036) uses W3C PROV, whose inverse of wasDerivedFrom is hadDerivation (PROV-O inverses note). source_for comes from stac-spec#1179. I kept the underscore to pair with derived_from, but I'm open to derivation/had-derivation if you prefer PROV alignment.

@m-mohr

m-mohr commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

No, I have no strong preference. We can use source_for.

Comment thread README.md
Comment thread README.md Outdated
Co-authored-by: Matthias Mohr <m.mohr@moregeo.it>

This comment was marked as resolved.

@m-mohr
m-mohr merged commit 34e2f94 into main Oct 9, 2026
3 checks passed
@m-mohr
m-mohr deleted the forward-provenance-relation-type branch October 9, 2026 11:17
@fmigneault

fmigneault commented Oct 10, 2026 •

Copy link
Copy Markdown

Just saw this a bit late.

How about used_by (i.e.: as for prov:wasUsedBy), the recommended inverse of used (https://www.w3.org/TR/prov-o/#inverse-names-table)?

While a derived_from (prov:wasDerivedFrom) can be used to reflect an entity transformed to another, is it safe to say that, inversely a "source" was employed without providing anything regarding what what it was "used by"?

It is a bit confusing because the https://github.com/stac-extensions/processing#relation-types table employs specifically "that was used as input data" for the derived_from description, but then doesn't employ used for the inverse. There also a mixture of incorrect PROV Entity/Activity concepts relationships happening.

It would make a lot of sense to employ used_by when a processing:software or processing:expression (the processing Activity) is involved

     ┌──rel:"used_by"─┐ -------------┐ (same STAC)
     │                ▼              ▼ 
rel:"source"  -> processing:* -> derived 
[STAC Entity]    [Activity]      [STAC Entity]
     ▲                               │
     └────── rel:"derived_from" ─────┘

Since the processing:* are annotated within the same document of the derived STAC Entity resulting from applying that processing activity, that would work. There would only be a requirement that the rel: used_by STAC being referenced should contain a processing:* definition.

@m-mohr

m-mohr commented Oct 10, 2026

Copy link
Copy Markdown
Contributor

We haven't released yet, feel free to open a PR.

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

Successfully merging this pull request may close these issues.

Relation type for forward provenance

4 participants