Naming of elements/properties #165
Assignees
Labels
Comments
|
1 - The working group has discussed and has decided to keep the same naming of identifiers and use the label as the human-readable text. The latter would have "has x" for properties etc. We did not want to do wholesale changes to the URIs unless there were broken. 2 - See 1) 3 - inheritRelation has now been deprecated 4 - We would argue that Privacy is a type-of Policy: https://en.wikipedia.org/wiki/Privacy_policy 5 - We agree and are discussing that here #154 (We may deprecate Set) 6 - I have updated the Label (but see 1) as well) 7 - Have removed "mechanism" for "strategy" (as that what is actually is). 8 - No, but the label is ok. 9 - No real reason. Examples here use upper-case: https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Equality_and_Inequality_of_Individuals 10 - Updated the labels. |
riannella
moved this from Wide/Horiz Review
to Completed (Last Call)
in ODRL Deliverables Review
|
1/2. Where is the group discussion? I'm curious to see the arguments.
I know that identifiers are technically not semantically meaningful. But when you start minting some that are meant to have a meaning in order to help users of your vocabulary, you’d rather do it well.
Of course there are valid concerns when one embarks on changing names/identifiers, especially for legacy applications. But are there so many implementations of POE already? And are they implementing all of POE, forcing you to freeze all names/identifiers?
Note that I’m not asking to re-open the discussion on all names. At a minimum, I’d implore you to make minor changes for elements that you know have not been implemented, when they can clarify the meaning *a lot*.
And mind that the POE group is now extremely familiar with what you’re creating. I can also say that I can live with the current namings, even if I don’t like them. But I too was familiar with ODRL when I started reading POE. It's not like an implementer who would have to start from scratch! We all have to do a big effort to put ourselves in the shoes of someone who’d discover your model and vocabulary for the first time.
Some basic principles:
- abbreviations are not really needed.
- heterogeneity in naming conventions across an ontology is really not great. Especially when it concerns elements that are in one same part of an ontology, like siblings.
- have same names for different resources is a bad decision, even with upper/lower-case distinction. Remember that when someone types http://Google.com or http://google.com in their browser they one ends up at the same place. I know that technically there's a difference, but why on Earth inflict this to your implementers? (this is real-life experience: in my environment, even skilled metadata specialists sometimes make mistakes and say, write skos:PrefLabel instead of skos:prefLabel...)
Finally, the solution to use 'human-intended' labels that are better, e.g. ‘has X’ instead of ‘X’ for a property, can help. But it won’t if in practice you’re always using ‘X’ when refering to the property in the documentation, as you currently do in the section headings for these properties.
3. Great.
4. I agree that according to your semantics Privacy is a type of (well, a subclass of) Policy. But I already understood this. My point is that the name of the class is confusing because Privacy is its own notion. It is probably revealing that the Wikipedia URL you use for you point is https://en.wikipedia.org/wiki/Privacy_policy, *not* https://en.wikipedia.org/wiki/Privacy.
5. That would make the trick. But as soon as #154 has not resulted in deprecating set, this issue #165 can't be closed.
6. There's a typo in "4.19.1 Conflict Stratey Preference" but this is better. And regarding your reference to your answer to 1, I will also point to my reaction about 1 :-) especially with the question, whether there are many implementations that make reference to ConflictTerm explicitly. I guess most would refer to *instances* of the class, not to the class itself.
7. Strategy is better than mechanisms indeed. But I can still write my comment in almost the same way as earlier:
One would expect that odrl:conflict relates a Policy to some sort of conflict (4.19.2). But the definition mentions ‘conflict-resolution strategy’ which is not the same thing. The label (‘Handle Policy Conflicts’) sounds like a different thing altogether. It seems like using the definition term or the label for minting a new identifier would help implementers.
8. Indeed :-) It's still the same discussion. Except that this one is more benign. Just occasionally causing some glitches when people (including me) try to write the name of the property manually. Hoping this will not result in worse effect, e.g. if a developers manually the URI wrongly in a piece of code or data.
9. Indeed both conventions have been used. It would be great however if POE just used the same convention across the board. Heterogeneity brings unnecessary cognitive efforts for readers/implementers.
10. Same reaction. The update of the labels certainly help (really!), but the heterogeneity in how the instances are named remains, alas.
…On 05/05/17 03:31, Renato Iannella wrote:
1 - The working group has discussed and has decided to keep the same naming of identifiers and use the label as the human-readable text. The latter would have "has x" for properties etc. We did not want to do wholesale changes to the URIs unless there were broken.
2 - See 1)
3 - inheritRelation has now been deprecated
4 - We would argue that Privacy is a type-of Policy: https://en.wikipedia.org/wiki/Privacy_policy
5 - We agree and are discussing that here #154 <#154> (We may deprecate Set)
6 - I have updated the Label (but see 1) as well)
7 - Have removed "mechanism" for "strategy" (as that what is actually is).
8 - No, but the label is ok.
9 - No real reason. Examples here use upper-case: https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Equality_and_Inequality_of_Individuals
10 - Updated the labels.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprSrTOIF1CY-X-nmHI-OxcdHfkLw-ks5r2nvygaJpZM4NNsJd>.
|
|
1/2 - There was some discussion here: There are 4 implementors we surveyed last year (who all use the current uris): 4 - So you prefer to label it "Privacy Policy"? What about the others...add "Policy" to their labels? |
|
On 18/05/17 06:06, Renato Iannella wrote:
1/2 - There was some discussion here:
https://lists.w3.org/Archives/Public/public-poe-wg/2017Jan/0001.html
There are 4 implementors we surveyed last year (who all use the current uris):
https://www.w3.org/2016/poe/wiki/images/8/88/ODRLImplementationSurvey-2016-Dec-07.pdf
If the group think these implementers would be against any changes, then so be it.
This said I would still have a check with the people who submitted them: are they real production systems?
You may even submit them the changes.
4 - So you prefer to label it "Privacy Policy"?
Yes
What about the others...add "Policy" to their labels?
For the sake of homogeneity you may do it. But it's far from necessary, because they are much less ambiguous. In fact there could be some dangerous overlap. I.e. "Agreement" already carries the right meaning, adding "Policy" could make one wonder what happens.
|
|
Actually it is acceptable to change names - and even models much much later than the rec stage that you're currently in - that's what happened for us who were implementing the Web Annotation standard last year.
So the group should really do what they feel is right and not feel strongly committed to keeping any implementation of an earlier ED workable.
…On 18/05/17 06:06, Renato Iannella wrote:
1/2 - There was some discussion here:
https://lists.w3.org/Archives/Public/public-poe-wg/2017Jan/0001.html
There are 4 implementors we surveyed last year (who all use the current uris):
https://www.w3.org/2016/poe/wiki/images/8/88/ODRLImplementationSurvey-2016-Dec-07.pdf
4 - So you prefer to label it "Privacy Policy"? What about the others...add "Policy" to their labels?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnpraEKIgJddLww21AHzA8XSRev0EL9ks5r68O-gaJpZM4NNsJd>.
|
riannella
added a commit
that referenced
this issue
Jun 7, 2017
|
I have updated the label to "Privacy Policy" commit c1aa20d |
riannella
moved this from Completed (Last Call)
to Proposed Solution
in ODRL Deliverables Review
|
Great for "Privacy Policy"!
About the naming issue (1/2 and the bits in other comments that were about changing the URIs) I am still skeptical. You say it's been discussed at
https://lists.w3.org/Archives/Public/public-poe-wg/2017Jan/0001.html
but I can't find it mentioned there.
I still think it would be worth discussing it and with the implementers. As said above at this stage of the WG it should be acceptable to change URIs. And they may have to re-implement things anyway as you've added or deprecated features.
|
|
(Wasn't the best documented discussion ;-) The point was that the URIs are not broken. Stuff has been added/deprecated, but exisiting stuff remains unchanged. Our work is based on exisiting deliverables, and not a new spec. |
|
Is this in your charter, that you have to b backward-compatible?
Being based on a deliverable doesn't necessarily mean that you have to keep all URIs. It's a CG deliverable, things can change (unless you would have a very wide base of stable implementations).
Don't take me wrong, I understand if you end up keeping the old URIs. After all I was once in a WG (SKOS) that kept old URIs even if all of us didn't like them. But that was after a long discussion.
I'm just insisting because I feel that the arguments raised are not super-strong. It's maybe a matter of documentation, as you say. But as a stubborn reviewer now having discussed this with you for quite a while, I have to check all the discussions have been had.
…On 19/06/17 03:08, Renato Iannella wrote:
(Wasn't the best documented discussion ;-)
See "benws: having 2 URIs for the same property?"
The point was that the URIs are not broken.
Stuff has been added/deprecated, but exisiting stuff remains unchanged.
Our work is based on exisiting deliverables, and not a new spec.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnpra0OCezsqksxJAPILS73L7V4YYjMks5sFcn8gaJpZM4NNsJd>.
|
|
Oh, and not only because I'm keen on long discussions: I do really think that some of the naming issues do not help POE adoption. |
|
Is there was empirical evidence on the impact of adoption and URI names? I've spent many years with the SNOMED ontology: http://bioportal.bioontology.org/ontologies/SNOMEDCT with URIs like: http://ihtsdo.org/snomed/SCT_49872002 Business drives adoption :-) |
|
Well, at least there is the empirical evidence that it made things more difficult to understand for me ;-)
(and also for you in the case of SNOMED-CT, I guess).
Note that I can live cumbersome naming choices. What bothers me most is if there are inconsistencies and conflicts in the naming. For example doing a fictious adaptation in the SNOMED case:
- one virus is named SCT_49872002 while another wirus would be named SCT49872003
- one virus is SCT_49872002 but there's also another resource called sct_49872002, which means something else (say, 'organism is infested by virus 49872002')
|
|
And I would certainly agree with you in an ontology with literally over a million URIs, that random underscores are not helpful ;-) But for us, Permission V permission (like in here: https://www.w3.org/2016/poe/wiki/Policy_Inference) is not so critical... |
|
I understand that for you it's not critical. And I can also live with it probably. But this is not only about us. As I said earlier, we're not an implementer who would have to start and read everything from scratch. We all have to do a big effort to put ourselves in the shoes of someone who’d discover your model and vocabulary for the first time.
|
|
Thanks @aisaac - closing this issue |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@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.
The text was updated successfully, but these errors were encountered: