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
Hi all,
Not sure if I'm missing something so feel free to correct me.
It seems that the spec allows for, essentially, a directory structure that lets you nest objects. My question is: given this, it seems that we should provide:
a) a path and / or
b) a parent id
This means that given a drs id, you can't get a sense where in the dataset hierarchy a given object lives.
Is that something that's planned in the spec at some point or am I thinking about this wrong?
The usecase is that a user may get a DRS ID for a file that has a dependency on another file in the same "directory" and with the current spec, I don't really know how to model that without the starting file knowing what it's "directory" even is.
The text was updated successfully, but these errors were encountered:
In the mean time, we're using the aliases field to store this path information but that feels wrong. Is there an accepted pattern where we could a an extra namespaced field (e.g. x-object-path) to the DrsObject? Are we allowed to add fields to objects? I couldn't find anything in the spec saying one way or another
Hi all,
Not sure if I'm missing something so feel free to correct me.
It seems that the spec allows for, essentially, a directory structure that lets you nest objects. My question is: given this, it seems that we should provide:
a) a path and / or
b) a parent id
This means that given a drs id, you can't get a sense where in the dataset hierarchy a given object lives.
Is that something that's planned in the spec at some point or am I thinking about this wrong?
The usecase is that a user may get a DRS ID for a file that has a dependency on another file in the same "directory" and with the current spec, I don't really know how to model that without the starting file knowing what it's "directory" even is.
The text was updated successfully, but these errors were encountered: