Closed akleinau closed 4 years ago
"has" is not a good SuperProperty. E.g.:
these relations can't be implemented in a monohierarchy
“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.
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".
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:
@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
@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.
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?
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.
@l-emele @stap-m What do you think? Any objections to deleting the unused and undefined object properties?
How can we describe the relations in the example sheets without having them in the ontology?
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?
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)
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
I have no objections against deleting the unused and undefined object properties.
ok I'll delete them for now
so next steps:
I want to delete:
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.
* "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.
I'm not sure about the "has ..." classes:
* "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.
I guess we should open an issue for assumptions, I'll make one :)
so to summarize and continue the ideas from above:
delete:
I agree.
I'll open a PR.
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)
- has_resolution with has_temporal_resolution and has_spatial_resolution
What would be the applications for these properties in other modules that oeo-model?
you are right, I can't find any. So leave that and put the others in oeo-shared?
I'll make a pull request
next step are definitions. We need ones for the followings, ideas are added behind:
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.
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
@jannahastings, @stap-m do you have comments or can I implement?
- 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!
@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?
@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?
@jannahastings sector is through, this can be implemented now :)
Okay :-D
right now there is almost no object property hierarchy and many properties are not in the right subclass (like many of the has_... properties)