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

observed by has type organization instead of instrument #1459

Open
CDiGallo opened this issue Aug 17, 2023 · 2 comments
Open

observed by has type organization instead of instrument #1459

CDiGallo opened this issue Aug 17, 2023 · 2 comments
Assignees

Comments

@CDiGallo
Copy link
Contributor

Is your feature request related to a problem? Please describe.
In the Cube-Datamodel the observed-by property (https://cube.link/observedBy) is interpreted as the publishing organization see:
https://s.zazuko.com/CRAJBm
If you compare it to what in cube.link the example is:
https://cube.link/#example-simple-observation

You'll see, the example says "cube:observedBy "
It makes a lot more sense to write to every value, on which kind of instrument is based on, than it to designate, which office is dataowner on this datapoint.

Describe the solution you'd like
this is part of a bigger problem, which has half a solution. What kind of responisiblity do certain entities have over a dataset and what kind of properties are linked to that.
(responsible from less to more)

  1. Contact Person who made the dataset on LINDAs
  2. Office which is Data Owner
  3. Organization that actually generated the data.

So my solution would be that we stick with the cube.link-meaning and implement a feature in CC what kind of "instrument" the datapoint is generated from.
Otherwise I'd consider actually removing this property. To me it seems as if it only would waste diskspace, the organization is usually implied on the datasetdescription and the named graph.

Additional context
This has low priority.

@tpluscode
Copy link
Collaborator

I very much understand this concern. It has always rubbed me the wrong way that the organisation is the "observer" for entire cubes.

The observedBy property is required so we're not likely to remove it. Hence, the decision was made to fall back to the organisation itself

I can only think of having in any given cube a dedicated column mapped to cube:observedBy. Likely as link to a Concept table. If any sucha mapping would exist, Cube Creator would not fall back to the current behaviour.

@ktk
Copy link
Member

ktk commented Aug 29, 2023

Not sure I follow the discussion but the point of cube:observedBy is to have a way to point to whatever made that observation. That is a bit less important in cases where someone aggregated the data already but this can be super useful if this comes directly from a sensor for example. There are many use-cases where knowing this is vital for data interpretation.

A proper observation does need it, we did not make that optional.

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

5 participants