Scope of scope

[jaygee-on-github]

In DCAT a resource like a Dataset has a Distribution. It seems that when in the Scope section we restrict resources to "static" resources, we are taking a keyhole view of a resource. Excluding resources that have APIs is only part of the restriction. Increasingly, distributions are becoming the product of AIs. In this event we will represent the distribution and not the "resource as a whole". Arguably, given the scope of scope here, isn't our understanding of resources just a collection of distributions without any relationships?

I don't quarrel with this given our purpose. That being said, can't we have our cake and eat it too (as opposed to just letting them eat cake)? I am thinking about "isBasedOn" in CreativeWork as a recommended property. If a keyhole is a circle, isBasedOn might enable us to square the circle. I was even going to say that isBasedOn is cheap. But I know that will be proven wrong.

I have been reading alot about what AIs do with rasters lately. It is getting curiouser and curiouser. That is my use case.

[smrgeoinfo]

How are you envisioning using 'isBasedOn'?

The idea of 'static' is that the 'distribution' for the resource described by the metadata does not change with time. This might be a resource that has only one digital representation, or a resource that has multiple representation (different distributions). The idea being that these representations/distributions remain the same at a bitstream level, i.e. they have a checksum fingerprint that defines identity.

We were thinking that to keep this initial version simple, we intentionally ruled out API based distributions, for which the identity of the distribution is a combination of the definition of the API and the data (if any) behind the API. And also dodge APIs that operate on user provided data input that have even fuzzier identity conditions. Continuously accruing time series as well...

Hopefully we'll get to those....

[jaygee-on-github]

Stephen:

My use case is that an ai produces a vector (v) from a raster (r):

v = ai(r)

And the vector v is published.

In this use case v has a checksum fingerprint and r has one too.

isBasedOn could refer to r.

Isn’t that true even if r doesn’t tell the whole story?

And doesn’t this way capture both the resource and the distribution?

Jay

On Jul 5, 2023, at 2:14 PM, Stephen Richard @.***> wrote:

How are you envisioning using 'isBasedOn'?

The idea of 'static' is that the 'distribution' for the resource described by the metadata does not change with time. This might be a resource that has only one digital representation, or a resource that has multiple representation (different distributions). The idea being that these representations/distributions remain the same at a bitstream level, i.e. they have a checksum fingerprint that defines identity.

We were thinking that to keep this initial version simple, we intentionally ruled out API based distributions, for which the identity of the distribution is a combination of the definition of the API and the data (if any) behind the API. And also dodge APIs that operate on user provided data input that have even fuzzier identity conditions. Continuously accruing time series as well...

Hopefully we'll get to those....

— Reply to this email directly, view it on GitHub https://github.com/Cross-Domain-Interoperability-Framework/Discovery/issues/8#issuecomment-1622247575, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAZGN7KSTGBZ5TEDBM74HALXOWVJVANCNFSM6AAAAAAZ5NB3QA. You are receiving this because you authored the thread.

[smrgeoinfo]

In your example, my question would be is the derived vector a representation of the same resource represented by r, or is it a new resource basedOn r. I would favor the second view.