search

w3c / odrl

ODRL Community Group Repository
https://www.w3.org/community/odrl/
Other
18 stars 9 forks source link

Create asset Action not present in ODRL #35

Open woutslabbinck opened 5 months ago

woutslabbinck commented 5 months ago

In an usage control enforcement project, I am trying to use ODRL as a language as policy language for CRUD decisions.

To the best of my knowledge, it is not possible to state with an ODRL Rule to declare an odrl:Action that an entity is allowed to create an asset.

In an issue on the aforementioned project, I argue that it is possible however to use odrl:use for this purpose. The problem with odrl:use, however, is that it allows for way more than just creating an asset.

My question thus is, shouldn't it be possible to state with ODRL that an entity is allowed to create an asset? (e.g. by using an action such as odrl:create with as description "The act of creating an Asset")

riannella commented 5 months ago

Yes, there is no restriction on adding a new "ex:create" action (in your profile). The challenge was that a Policy would typically refer to an Asset that already exists (hence it has already been created). In your case, the Asset could be an AssetCollection (something you can ID) such as a file system.

besteves4 commented 5 months ago

But shouldn't we be able to express policies for assets that do not exist yet? Example: I might want to say that I want the data generated by my smart-watch to be stored in my data vault and used in a certain way even though it has not been generated yet. The same applies for data that is not personal data, e.g., data generated by IoT sensors. So, it is something that we can already see that will have applicability across use cases, so why not consider it for a future iteration of ODRL instead of instantiating it in multiple ODRL profiles?

csarven commented 5 months ago

I don't find the notion "existing" specific enough. An identifier being expressed and discoverable or dereferenceable may be more useful.

Technically a policy for a URI that's not dereferenceable is possible. Or possibly even a bnode instead of a URI.

Alternative approach is to refer to a container/collection/storage of sorts that will eventually contain the specific asset.

(I don't know what a "data vault" is.. is that expressed in a spec / document somewhere or random branding out there?)

besteves4 commented 5 months ago

@csarven agreed. I want to be able to say that the target of my policy is some instance of dpv:Data, for instance, as I might not even know where that particular piece of data is.

(AFAIK "data vault" is being used as you would use data stores or data wallets, but it is not very important for the point I wanted to make - I don't care very much where the data is stored as long as I can decide who has access to it or what can be done with it)