Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

class-specific properties considered harmful #17

Open
VladimirAlexiev opened this issue Jul 14, 2017 · 2 comments
Open

class-specific properties considered harmful #17

VladimirAlexiev opened this issue Jul 14, 2017 · 2 comments

Comments

@VladimirAlexiev
Copy link
Member

VladimirAlexiev commented Jul 14, 2017

Consider these properties:

They mean exactly the same and the unit is the same (km).
They just pollute the namespace (eg if you look in http://ismaro3.ddns.net/webprotege, you'll see a bunch of props with the same name and wonder which one to use) and add unnecessary complexity.

apoapsis_km could make sense. But Galaxy/apoapsis makes no sense at all.

Class-specific properties are supposed to provide more natural units, eg "cm" for person height as opposed to "m" for height, which is the default. But (observed in http://vladimiralexiev.github.io/pres/20150209-dbpedia/dbpedia-problems-long.html#sec-7-5):

  • you need to know such per-class property exists
  • you need to know the unit (eg see http://dbpedia.org/ontology/Person/height), whereas the universal props use SI
  • you cannot use them with prefixes because eg dbo:Person/height is not a valid prefixed name. This should be changed to eg dbo:Person_height (or even better dbo:height_Person)

Because of the inflated complexity and the inconveniences described above, I propose to remove these props, and replace them with unit-specific props, eg apoapsis_km, height_cm

@reeshabhranjan
Copy link

Is this still open and worth to be worked on?

@JJ-Author
Copy link
Contributor

JJ-Author commented Mar 5, 2020

Since the feature seems rarely used it does not really make sense to work on it or the impact would be really low. One contribution could be to actually analyze the usage in order to quantify it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants