Create proper object property hierarchy

[akleinau]

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]

"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

[fabianneuhaus]

“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]

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]

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:

• there are so many has-relations, "has_license", "has_logo", "has_software", are they necessary or can we replace (some of) them with the standard "has_part" or "has_participant"?
• there are relations like "is_available_on_github" which have true or false as range. We have a boolean variable class, do we just link them to those? Are those relations helpful and needed?

[akleinau]

@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]

@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]

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]

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]

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

[akleinau]

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

[stap-m]

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]

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]

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]

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

[akleinau]

ok I'll delete them for now

[akleinau]

so next steps:

• delete unused properties with definitions that have no use
• see if used properties can be replaced by extern ro-properties
• see if an own module for our properties makes sense

[akleinau]

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

[akleinau]

• "makes_assumption": we have a class "Assumption" so we can use 'has part' (some assumption) of the ro instead
• maybe covers_region, covers_technology and covers_timeframe because they can be replaced with has_part or has_resolution, etc?

[jannahastings]

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]

* "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]

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

• has_author: we have a class author but if we use 'has part' instead and assign a person with the role author this doesn't guarantee that person is actually the author of this specific thing
• has_client
• has_contact
• has_funding_source
• has_institution
• has_progamvariable: I guess that can be replaced by 'has part' some variable?
• has_tool: we haven't even defined what a tool is, delete

[l-emele]

* "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]

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

[akleinau]

so to summarize and continue the ideas from above:

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
• makes_assumption": we have a class "Assumption" so we can use 'has part' (some assumption) of the ro instead
• covers_region, covers_technology and covers_timeframe because they can be replaced with has_part or has_resolution or just covers
• has_program_variable: can be replaced with 'has part'
• has_tool: delete as we don't have a class called 'tool'

[l-emele]

I agree.

[stap-m]

I'll open a PR.

[akleinau]

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:

• has_resolution with has_temporal_resolution and has_spatial_resolution
• process_attribute_of and has_process_attribute
• uses and is_used_by

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]

• 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]

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

[akleinau]

I'll make a pull request

[akleinau]

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

• uses: A relation that holds between a continuant and another continuant it uses to function.
• has_model: A relation between a continuant and a model of it. -has_globalwarmingpotential: A relation between a portion of matter and the global warming potential it has.
• is_connected_to: A relation that holds between two nodes in a graph that are connected to each other through an edge.
• has_sink: A relation that holds between a directed graph and a node in that graph that has edges ending but not starting there.
• has_source: A relation that holds between a directed graph and a node in that graph that has edges starting but not ending there.
• is_unit_of: A relation between a unit and the physical entity it measures.

[l-emele]

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]

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]

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

[jannahastings]

• 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]

@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]

@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]

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

[jannahastings]

Okay :-D