Re: [poe] Naming of elements/properties

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 <https://github.com/w3c/poe/issues/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 <https://github.com/w3c/poe/issues/165#issuecomment-299351265>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprSrTOIF1CY-X-nmHI-OxcdHfkLw-ks5r2nvygaJpZM4NNsJd>.
>


-- 
GitHub Notification of comment by aisaac
Please view or discuss this issue at https://github.com/w3c/poe/issues/165#issuecomment-302265843 using your GitHub account

Received on Thursday, 18 May 2017 00:17:06 UTC