Profile Best Practice document with alternative text about Policy and subclasses of Rule

Hi all,

at the call on 8 June this raised erratum was discussed:
<https://github.com/w3c/poe/issues/303>
https://github.com/w3c/poe/issues/303

Simply summary: the ODRL data model and vocabulary define that only a
single specific subclass of Rule can be used as type for the Policy
properties permission, prohibition  and obligation.

Open issue: how to use subclass of Rule defined by a Profile in a Policy?
By the current Recommendation this is not easy:

 

At the call we discussed two options:

a.	The data model and the vocabulary stay untouched, the only solution
is creating a new property in a new subclass of Policy and to define the
new Rule subclass as type of this new property.
Pro: no change of the Recommendation is required
Con: a kind of pointless rule dummy must be used with permission or
prohibition or obligation if the goal of the news Profile is to use only
new subclasses of Rule.
b.	Currently the vocabulary defines for the Policy property permission
[1]: its type (Range) is Permission [2], and Permission defines In Range
of: permission.
(Corresponding definitions are applied to the properties prohibition [3]
and obligation [4]).
This is changed to permission/prohibition/obligation have  as type (Range)
Rule [5] – this opens the window of opportunity for applying any subclass
of Rule as type.
Open issue: what about this “In Range Of” in the vocabulary, this is not
reflected explicitly by the formal OWL documents of the vocabulary, may be
generated from the range setting of properties. “In Range of” appears to be
not a relationship defined for RDF or OWL.

 

General note: at the call David reminded us of sticking to the base design
of ODRL, and this includes only permission, prohibitions and obligations
should be expressed as Rule, not anything away from it. We may consider how
to guarantee that. This is my suggestion:
<https://github.com/w3c/odrl/issues/10>
https://github.com/w3c/odrl/issues/10

 

Based on this discussion I modified – as agreed at the call – the Profile
Best Practice document  <https://w3c.github.io/odrl/profile-bp>
https://w3c.github.io/odrl/profile-bp

*	ALTERNATIVE TEXT is shown in the section Additional Rule Subclasses
<https://w3c.github.io/odrl/profile-bp/#rule>
https://w3c.github.io/odrl/profile-bp/#rule
*	ALTERNATIVE TEXT is shown in the section Additional Policy
Subclasses https://w3c.github.io/odrl/profile-bp/#policy 
*	ALTERNATIVE TEXT is shown in the section What may be ignored, and
what not https://w3c.github.io/odrl/profile-bp/#oos1
*	“ALTERNATIVE TEXT no change applied …” reflects option a) above
*	“ALTERNATIVE TEXT constraint of types …” reflects option b) above

 

What’s next:

1.	Please review if the created ALTERNATIVE TEXTs reflect options a)
and b) in their context properly – prior to the next call on 6 July.
… and post any comments to this email list.
2.	At the next call we should agree if we keep both alternatives in
the Best Practice or if we select one of them as “the solution”.

 

Best,

Michael

 

 

[1]  <https://www.w3.org/TR/odrl-vocab/#term-permission>
https://www.w3.org/TR/odrl-vocab/#term-permission

[2] https://www.w3.org/TR/odrl-vocab/#term-Permission

[3] https://www.w3.org/TR/odrl-vocab/#term-prohibition

[4] https://www.w3.org/TR/odrl-vocab/#term-obligation 

[5] https://www.w3.org/TR/odrl-vocab/#term-Rule 

 

=============================================================

Gesendet von / sent by:

Michael W. Steidl

 <http://www.linkedin.com/in/michaelwsteidl>
www.linkedin.com/in/michaelwsteidl 

Email: mwsteidl@ <http://www.newsit.biz/> newsit.biz 

1180 Wien/Vienna – Österreich/Austria