Check if ids:contractOffer belongs to a parent class in ODRL or DCAT

[changqin26]

why ids:contractOffer is not a subproperty of odrl:hasPolicy (keeping in mind that according to Hosseinzadeh, Arghavan  no one uses odrl:hasPolicy

[changqin26]

In DCAT, there is a property called dct: rights describing all the other types of rights statements except for license and access rights. According this definition, it can be the parent property of ids:contractOffer.

However, in the definition it also mentions:
"in the particular case when rights are expressed via ODRL policies, it is recommended to use the odrl:hasPolicy property as the link from the description of the cataloged resource or distribution to the ODRL policy"

Since Hosseinzadeh Arghavan said that no one uses odrl:hasPolicy, does it also imply that no one uses dct:rights?
Should we still introduce dct:rights?

@clange

[riannella]

odrl:hasPolicy is used by DCAT3.
Other ontologies use it: https://ai.wu.ac.at/policies/orcp/regulatory-model.html#hasPolicy

[changqin26]

@riannella, many thanks for your hint!

[changqin26]

In the IDS infomation model, we have:
ids:Resource ids:contractOffer ids:ContractOffer
ids:ContractOffer rdfs:subClassOf ids:Contract, odrl:Offer
ids:Contract & odrl:Offer rdfs:subClassOf odrl:Policy

And in the ODRL:
dcat: Resource odrl: hasPolicy odrl: Policy

From the given statements, it makes sense to set:
ids:contractOffer rdfs:subPropertyOf odrl:hasPolicy

@hosseinzadeha, can you please confirm the conclusion here? Thank you!

[hosseinzadeha]

Hi,

From policy specification point of view, there are two ways to relate a policy and the data:

1. Setting the "target" in the policy.
2. Setting the "hasPolicy" in the asset description.

Currently, the first option is more used in the implementations but both are completely fine.

ids:contractOffer rdfs: subClassOf odrl: hasPolicy is wrong. An entity (ContractOffer) cannot be a subclass of a relation (hasPolicy).

And regarding the dct: rights:
We can define "read right", "write right", "display right", etc. but we cannot express Usage Control policies (i.e. contracts) only with the rights. Because Usage Control restrictions are more that providing rights. therefore, dct:rights cannot be a parent for a Contract.

[changqin26]

Hi @hosseinzadeha ,

we have the relation ids:contractOffer and entity ids:ContractOffer. What we want to add is the relation ids:contractOffer as the subClassOf relation odrl:hasPolicy.

[Brandstaedter]

shouldn't a relation indicate that it is a relation, like ids:hasContract which indicates a link to the Asset Contract and why do you need this if Contract is a subclass of odrl:Policy, so you can add to the Property hasPolicy just the URI of the Contract?

[changqin26]

Hi,

I am really sorry for this misleading typo. It should be subPropertyOf instead of subClassOf. If we say `ids:contractOffer is the subProperty of odrl:hasPolicy', would it be right in this case?

[riannella]

Yes, rdfs:subPropertyOf is correct.
You can also se the range to odrl:Offer (i assume)

[JohannesLipp]

Decision: Add ids:contractOffer rdfs:subPropertyOf odrl:hasPolicy to the IM, and add odrl:hasPolicy to the CodeGen helper class, if needed.