[poe] Issue: Naming of elements/properties marked as Vocab

riannella has just labeled an issue for https://github.com/w3c/poe as "Vocab":

== Naming of elements/properties ==
@aisaac

Remarks on the naming of POE elements:

- it’s really confusing to have classes and properties that have the same identifier, the only difference being capitalization, e.g. ‘Permission’ and ‘permissions’. I know you may inherit this from earlier ODRL work, but as POE is not yet a Recommendation, it would be useful to question that. Having the property identifier for “Has Permission” be ‘hasPermission’, ‘hasPermissions’ or ‘permissions’ would already be way clearer for implementers.

- for the possible values of odrl:conflict attribute, why is one abbreviated (‘perm’) but not the others (‘prohibit’, ‘invalid’)? Homogenising the way they are identified would be good.

- the name of odrl:inheritRelation is quite confusing. It sounds as if it denotes the inheritance relation between policies. But this is the role played by odrl:inheritFrom. If the role of odrl:inheritRelation is to link to some “context of inheritance” (https://www.w3.org/TR/odrl-model/#inhertiance), why not naming it odrl:inheritanceContext?

- some sub-classes of Policy have strange names, like Privacy. This name is shorter than PrivacyPolicy, indeed, but it’s quite confusing as the bare word ‘privacy’ means something completely different from a policy. Compare with Agreement and Offer, which sound much better as direct sub-class of Policy: ’agreement’ and ‘offer’ are what the policy really is; ‘privacy’ is rather the object of the policy. See how ‘privacy’ could also be used in new ‘privacy agreement’ or ‘privacy offer’ kind of policies.

- ‘set’ is also strange. It’s not wrong, but the definition shows a problem: “Policy expression that consists of entities from the complete model.” This can be said of any POE Policy, no? ‘Open Set’ or ‘Open Policy’ would reflect better what is in the note in 4.2.6. Or maybe ‘Policy prototype’ or ‘Abstract Policy’?

- why using something as vague as ‘term’ for ‘ConflictTerm’ while the definition and note in 4.3.1 suggest that ConflictStrategy would be both more precise and fit to the semantics?

- one would expect that odrl:conflict relates a Policy to some sort of conflict (4.3.2). But the definition mentions ‘conflict-resolution mechanism’ which is not the same thing. The label (‘Handle Policy Conflicts’) sounds like a different thing altogether. Still it seems like using the definition term or the label for minting a new identifier would help implementers.
Same for odrl:undefined (4.4.2). At this point I must say that I’m not nitpicking for the fun of it. The fact that POE contains so many of these identifiers that very approximately represent the meaning of the class/property (one could even call them ‘false friends’) caused me to lose a lot of time figuring out the POE model itself.

- is there any reason that ‘inheritFrom’ is not ‘inheritsFrom’?

- why do identifiers of scopes (which are instances of classes) start with upper-case, that is, they use the usual convention for naming classes?

- why isn’t odrl:AllConnections named odrl:AllFirstLevelConnection, just the way odrl:All2ndConnections is named... (and then why isn’t it odrl:All2ndLevelConnections?). Why odrl:AllGroups and not odrl:AllGroupConnections? A bit of homogenisation here would be really good.


See https://github.com/w3c/poe/issues/165

Received on Tuesday, 2 May 2017 04:06:12 UTC