OpenEnergyPlatform / ontology

Repository for the Open Energy Ontology (OEO)
Creative Commons Zero v1.0 Universal
111 stars 23 forks source link

Create proper object property hierarchy #66

Closed akleinau closed 4 years ago

akleinau commented 5 years ago

right now there is almost no object property hierarchy and many properties are not in the right subclass (like many of the has_... properties)

akleinau commented 5 years ago

"has" is not a good SuperProperty. E.g.:

these relations can't be implemented in a monohierarchy

fabianneuhaus commented 5 years ago

“has” should not be in the ontology as property under any circumstances. Because “has” is an auxiliary verb and does not mean anything on its own. Unless it is used as a synonym for “owns” (like in “John has a car”), but in this case one should just use “owns”.

Of course, has_part or has_ancestor or has_neighbour etc. are fine, because in this case the “has” is accompanied with something that makes the property meaningful.

On 7. Nov 2019, at 09:18, akleinau notifications@github.com wrote:

"has" is not a good SuperProperty. E.g.:

has_sink starts with the prefix "has" and should therefore be a SubProperty of "has" has_sink is a SubProperty of is_connected_to which does not have the prefix "has" and is therfore not a SubProperty of "has". these relations can't be implemented in a monohierarchy

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenEnergyPlatform/ontology/issues/66?email_source=notifications&email_token=AAWE2W2ARVHQLJPLF7WHYITQSPFO3A5CNFSM4JKC2G42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDLS2YY#issuecomment-550972771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWE2W2XTWJJLUK2XRH2AN3QSPFO3ANCNFSM4JKC2G4Q.

fabianneuhaus commented 5 years ago

the same applies for other auxiliary verbs. E.g., is_part_of, is_ancester_of and is_connected_to are fine properties. But there is no property "is".

akleinau commented 4 years ago

There is a spreadsheet to fill out the missing definitions in #175. I started defining some of the relations but I'm having some problems:

akleinau commented 4 years ago

@jannahastings I think now is a good time to create the definitions for the missing object properties. I already started but encounted some problems like the ones above plus that we don't really have a form defined like the aristotelean form for entities. Also I felt with some properties that I just wrote them out as a sentence

jannahastings commented 4 years ago

@akleinau just an interim update: I have looked at the table and made a few notes, but I still need to look in greater depth at how often and where each of these are being used.

jannahastings commented 4 years ago

I added a column with the number of times the properties are used in axioms outside of the definition of the object property hierarchy. Most of these properties are not used at all! Many of them represent metadata about data instances and are thus not really "object properties" at all.

---> I propose that we just delete the ones from this list that are not being used?

akleinau commented 4 years ago

yes I think many of them are more thought for model or scenario sheets like these in the "examples" folder than for inside the ontology. like the examples/eGoDP_modelfactsheet.ttl.

jannahastings commented 4 years ago

@l-emele @stap-m What do you think? Any objections to deleting the unused and undefined object properties?

akleinau commented 4 years ago

How can we describe the relations in the example sheets without having them in the ontology?

stap-m commented 4 years ago

All the factsheets are going to be worked over anyway. Thus, in my opinion the properties can be deleted. But I didn't create them. Can we discuss this with the austhors?

akleinau commented 4 years ago

hmm, I couln't find out who added them. I added a column for "delete this and replace it with" to the excel sheet (link) though. But now I'm thinking if we should widen this to include all object properties (that are not imported)

akleinau commented 4 years ago

maybe deleting the unused ones and adding them later again when actually needed is actually the most efficient way, like @jannahastings proposed. I'll write Martin first though

l-emele commented 4 years ago

I have no objections against deleting the unused and undefined object properties.

akleinau commented 4 years ago

ok I'll delete them for now

akleinau commented 4 years ago

so next steps:

akleinau commented 4 years ago

I want to delete:

akleinau commented 4 years ago
jannahastings commented 4 years ago

I want to delete: "is_equivalent_to": if it's equivalent it shouln't be split into two classes? "uses_dataset": definition: "A relation that holds between a transformation and a dataset it uses as input." so we should use "has input" of the ro instead

Sounds good to me! For the "is equivalent to" there are built-in relations such as owl:sameAs if needed in an RDF triple store.

jannahastings commented 4 years ago
* "makes_assumption": we have a class "Assumption" so we can use 'has part' (some assumption) of the ro instead

This one is tricky. The assumption class gives mainly (only?) political / social assumptions as examples. And the relation definition refers to an assumption that is needed for the execution of a "transformation". It is difficult for me to imagine the sorts of transformations that are meant. Don't assumptions apply to whole models, or modelling processes, rather than just transformations? Either way, I agree that the relation can be deleted. I just wonder if we should think a bit more about the way that assumptions are used.

akleinau commented 4 years ago

I'm not sure about the "has ..." classes:

l-emele commented 4 years ago
* "makes_assumption": we have a class "Assumption" so we can use 'has part' (some assumption) of the ro instead

This one is tricky. The assumption class gives mainly (only?) political / social assumptions as examples. And the relation definition refers to an assumption that is needed for the execution of a "transformation". It is difficult for me to imagine the sorts of transformations that are meant. Don't assumptions apply to whole models, or modelling processes, rather than just transformations? Either way, I agree that the relation can be deleted. I just wonder if we should think a bit more about the way that assumptions are used.

Maybe we should discuss assumption first? The current definition is rather weird: An assumption is a statement about a property of a system or process that is considered to be true. To me an assumption does not have to be true as you often have scenarios (e.g. business-as-usual scenarios) where you use counterfactual assumptions.

akleinau commented 4 years ago

I guess we should open an issue for assumptions, I'll make one :)

akleinau commented 4 years ago

so to summarize and continue the ideas from above:

delete:

l-emele commented 4 years ago

I agree.

stap-m commented 4 years ago

I'll open a PR.

akleinau commented 4 years ago

As we now have an oeo-shared module I want to include the following properties in it that may be of use in more than one of the modules:

In that context I also want to delete covers and covers_energycarrier from oeo-physical as they aren't used there and need a publication/ model as domain (which is not included in oeo-physical)

stap-m commented 4 years ago
  • has_resolution with has_temporal_resolution and has_spatial_resolution

What would be the applications for these properties in other modules that oeo-model?

akleinau commented 4 years ago

you are right, I can't find any. So leave that and put the others in oeo-shared?

akleinau commented 4 years ago

I'll make a pull request

akleinau commented 4 years ago

next step are definitions. We need ones for the followings, ideas are added behind:

l-emele commented 4 years ago

has_globalwarmingpotential: It was intended to use this relation not with a process but with a portion of matter (i.e. greenhouse gases), see #29.

akleinau commented 4 years ago

has_globalwarmingpotential: It was intended to use this relation not with a process but with a portion of matter (i.e. greenhouse gases), see #29.

I updated it

akleinau commented 4 years ago

@jannahastings, @stap-m do you have comments or can I implement?

jannahastings commented 4 years ago
  • uses: A relation that holds between a continuant and another continuant it uses to function.

Maybe to avoid repeating 'uses' in the definition we could say 'requires' instead? I think it will sound more natural as well.

Otherwise no objections, looks good!

akleinau commented 4 years ago

@jannahastings "is_unit_of" is imported from UO where it too has no definition. So should I add the def to our module or add it in oeo-shared?

akleinau commented 4 years ago

@jannahastings I think we are ready to change the numerical identifiers, as all properties apart from the imported unit_of property have now definitions etc. Can you do it again? Maybe after the sector pull request?

akleinau commented 4 years ago

@jannahastings sector is through, this can be implemented now :)

jannahastings commented 4 years ago

Okay :-D