Open changqin26 opened 2 years ago
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
odrl:hasPolicy is used by DCAT3. Other ontologies use it: https://ai.wu.ac.at/policies/orcp/regulatory-model.html#hasPolicy
@riannella, many thanks for your hint!
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!
Hi,
From policy specification point of view, there are two ways to relate a policy and the data:
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.
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
.
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?
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?
Yes, rdfs:subPropertyOf is correct. You can also se the range to odrl:Offer (i assume)
Decision: Add ids:contractOffer rdfs:subPropertyOf odrl:hasPolicy
to the IM, and add odrl:hasPolicy
to the CodeGen helper class, if needed.
why ids:contractOffer is not a subproperty of odrl:hasPolicy (keeping in mind that according to Hosseinzadeh, Arghavan no one uses odrl:hasPolicy