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
The problem is that this kind of filter mechanism could return a list instead of a single entry. According to the PROV spec the uniques of a relation is defined by all formal attributes (eg form / to node). Maybe we can set a filter by this formal attributes.
This seems the best solution but also require to alter the BaseAdapter and all adapter implementations.
Also I really don't know if it is necessary to get only a single relation between to ProvElements. Is there any good use case for this?
The text was updated successfully, but these errors were encountered:
If we implement a method like prov_api.get_relation(matching_attributes) we should return list in every case, since its easier to process.
I don't think just return the relation itself is interesting.
At least it should return a list of all relations, including the involved node as well.
i.e.
But, usually it question would be like: "Which entities were in created in a particular process".
Isn't there a filter function that could solve such questions?
Currently the
ProvDb
class expose methods likeget_element(identifier)
this method returns 3 possible types:In order to provide a consistent we should discuss the advantage of a method like
get_relation()
For example:
The problem is that this kind of filter mechanism could return a list instead of a single entry. According to the PROV spec the uniques of a relation is defined by all formal attributes (eg form / to node). Maybe we can set a filter by this formal attributes.
This seems the best solution but also require to alter the
BaseAdapter
and all adapter implementations.Also I really don't know if it is necessary to get only a single relation between to
ProvElements
. Is there any good use case for this?The text was updated successfully, but these errors were encountered: