nemo-ufes / gufo Goto Github PK
View Code? Open in Web Editor NEWgUFO: A Lightweight Implementation of the Unified Foundational Ontology (UFO)
Home Page: http://purl.org/nemo/doc/gufo
License: Creative Commons Attribution 4.0 International
gUFO: A Lightweight Implementation of the Unified Foundational Ontology (UFO)
Home Page: http://purl.org/nemo/doc/gufo
License: Creative Commons Attribution 4.0 International
Describe the bug
The current version of gUFO (1.0.0) has the following statement: gufo:Mixin rdfs:subClassOf gufo:NonSortal
However, as there is no other gufo:NonSortal subclass, aren't these classes the same? In this case, they should be related through an owl:sameAs statement?
Expected behavior
Old statement: gufo:Mixin rdfs:subClassOf gufo:NonSortal
New statement: gufo:Mixin owl:sameAs gufo:NonSortal
I have two questions about the model below (picture and code block)
Content-wise:
We would like to indicate that a Person could fulfill a Organizational Role, but would not explicitly model all possible instances of Organizational Role as subclasses of Person.
The advantage of this is that we leave unspecified which subclasses can end up being added. We only model the fact that there are different subclasses of Position following from the Role that Position has.
Is this a 'correct' way to use gUFO?
Visually:
The property gufo:categorizes consideres Person and OrganizationalRole as instances of respectively gufo:Kind and gufo:Type.
The property :fulfillsTheRoleOf consideres Person and OrganizationalRole as classes.
How can we visualize efficiently the categorizes-relation between both classes without suggesting that instances of OrganizationalRole categorize instances of Person?
:Person a gufo:Kind ;
rdfs:subClassOf gufo:FunctionalComplex .
:OrganizationalRole a gufo:Type ;
rdfs:subClassOf gufo:Role .
:OrganizationalRole gufo:categorizes :Person .
:fulfillsTheRoleOf a owl:ObjectProperty ;
rdfs:domain ex:Person ;
rdfs:range ex:OrganizationalRole .
:ProgramManager a :OrganizationalRole .
:John a :Person ;
:fulfillsTheRoleOf :ProgramManager .
This question is closed for it contains an error and will be corrected and re-issued.
I just wanted to note that I have created a docker image for https://github.com/nemo-ufes/ontouml-lightweight-editor and pushed it to https://hub.docker.com/r/jeswr/ontouml if this is of use to anyone.
Is there a way in gUFO to express that an gufo:Aspect is static or dynamic, equivalent to typing Objects as (sub)kind, phase or role?
For example: ShirtSize is a static aspect of a Shirt, while PersonLength is a dynamic aspect of a Person.
How would you suggest to model statements in which multiple entities are involved, when using gufo?
Examples:
For example: given that some weapon types are banned by law, it seems you could model this as a property of WeaponType or as a specialization (ForbiddenWeapon/AllowedWeapon) of Weapon. A law would typically ban a weapon type, not an individual weapon, so modelling the ban as a property of WeaponType seems to make more sense. But what exactly would go wrong if you model it as a specialization of Weapon?
Is it possible to attach cardinality constraints to subproperties of categorizes/partitions? And if so, what does it mean?
E.g. PersonRole (0..*) - personRolecategorizesPerson (subpropertyOf gufo:categorizes) - (1..1) Person.
Would this mean that one instance of PersonRole (e.g. Student) categorizes exactly one instance of Person, and that an instance of Person can be categorized by 0 or more PersonRoles?
In the domain of law enforcement there is always quite a bit of uncertainty about what happened:
If we model these things as a gufo:ExtrinsicMode (suspicion, witness claim, etc) than we lose the structure of what it is that's being claimed.
If we model these things as true than we're technically lying.
Something like a gufo:ExtrinsicMode (suspicion, witness claim, etc) that refers to a named graph that contains what it is that's being claimed would seem like a solution, but doesn't seem possible with gUFO.
How would you model this type of uncertainty?
The instructions for citing gUFO could include the BibTex entry as well, for example:
@misc{almeida2019gufo,
title={{gUFO}: A lightweight implementation of the {Unified Foundational Ontology} ({UFO})},
author={Almeida, Jo{\~a}o Paulo A. and Guizzardi, Giancarlo and Falbo, Ricardo Almeida and Sales, Tiago Prince},
year={2019},
howpublished={\url{http://purl.org/nemo/gufo}}
}
As far as I know, adding URLs nicely requires additional packages, so my example uses howpublished
. The example also includes the publication year of gUFO, which is missing in the current citation instructions.
Just one additional observation: the deployed website and the latest commit do not match.
InheresIn is ranging over ConcreteIndividual. This means that dispositions can inhere in events and situations, which is probably unintended. In the UFO-B main paper (https://link.springer.com/chapter/10.1007/978-3-642-41924-9_27), trope can only inhere in objects (a subtype of endurants). However, a subsequent paper (https://content.iospress.com/articles/applied-ontology/ao190214) says, just like in gUFO, that dispositions can inhere in any concrete individual, which I believe is either a mistake or a design choice due to some desired or undesired inferences.
Indeed, in gUFO, that was a deliberate choice (https://nemo-ufes.github.io/gufo/#IntrinsicAspect): " Different from Guizzardi (2005), here we consider that aspects can inhere in concrete individuals in general, and not only in endurants." Why?
Describe the bug
IMHO, Collectives/Collections are relationally dependent on their composing members.
Please take a look at: OntoUML/OntoUML#70
Expected behavior
Creation of an axiom that states that gufo:Collection is subClassOf to the inverse of (gufo:isCollectionMemberOf min 2 gufo:Object)
I am building a software for automatically infer unknown gUFO classifications of OWL classes from known classifications from the same OWL ontology - for now, I'm working only with EndurantTypes. Running some tests, I noticed that some classes never had their gUFO classifications fully set because, e.g., they could be SubKinds or Sortals. I concluded that gUFO was projected like this because of the open-world assumption.
However, when talking to Tiago Sales, he told me that the user should set his/her classes as types of the gUFO leaf classes for the Types' hierarchy (Kind, SubKind, Role, Phase, Mixin, Category, RoleMixin, PhaseMixin) and that this was not the case only for the Individuals' hierarchy. I.e., the non-leaf classes in the types hierarchy should be "abstract" (not the best term for open-world).
I tried to verify this information using the documentation, but the only mentioning I could find for this idea was: "The most abstract classes in this structure mostly reflect the taxonomy of individuals.", which is not enough for the conclusion I had before talking to Tiago.
Hence, I propose:
When exporting from Visual Paradigm using the 'Export to gUFO' option, the complete gUFO structure is not exported. I believe it is deliberate, so just the necessary to represent what is in the modeling is exported.
For example:
1. when defining a Quality in the conceptual model, then in Protegé I want to assign a value (data property). But the hasQualityValue was not exported, so I have to create it manually or is there any way to export to gUFO by VP with it already created?
2. Another example is that all Kinds and Categories are being exported as FunctionalComplex, without going into detail in the Types structure. Is this also on purpose and is it correct?
I'd like to get a clear picture on mereology in gUFO, and as a starter I'd like to get an overview of the (object)properties that are typically used to express that phenomenon.
In reference to the article on mereology from the Stanford Encyclopedia of Philosophy, the core principles for parthood are characterized by relations that are either Reflexive, Transitive or Antisymmetric or combinations thereof, and of course relate parts with their wholes. I'm not sure but suggest the following ObjectProperties to be part of (pun not intended) such list of mereological properties:
Q1: Please correct me where I'm wrong, and add properties that I've missed.
Thanks in advance for your support.
Can we interpret all datatype properties, minus the functional properties (hasBeginPointInXSDDate hasBeginPointInXSDDateTimeStamp hasEndPointInXSDDate hasEndPointInXSDDateTimeStamp), as subproperties of concernsQualityValue, hasQualityValue or hasValueComponent?
Is your feature request related to a problem? Please describe.
I was trying to map the OntoUML classes stereotypes to GUFO and only two of them do not have the same label:
For the former, there is an rdfs:comment indicating the correspondence, while for the letter there isn't.
Describe the solution you'd like
It would be great to include in the Collection rdfs:comment the phrase "Corresponds to "Collective" in Guizzardi (2005).".
How do we classify Individuals like craters, bullet holes, tool marks, etc? Are these IntrinsicAspects? And if so are they Qualities or IntrinsicModes?
Is your feature request related to a problem? Please describe.
Whenever I have a look at your (otherwise very good) gUFO documentation, particularly on Object Properties, the characteristics of the property are not always mentioned explicitly. I consider this a shortcoming of the documentation, since it requires the user to look that up in the gufo.ttl file, which is unwieldy.
Describe the solution you'd like
Please add the characteristics, i.e., (inverse)functional, transitive, symmetric, asymmetric, reflexive, irreflexive, to each property in the documentation. This could be done in a similar fashion as in the Protégé documentation, an example shown below:
Describe alternatives you've considered
As indicated, this information indeed is available in the gufo.ttl specification. However, I consider that not the right location to search for information.
Is your feature request related to a problem? Please describe.
As far as I understand, gUFO is based on an older version and is thus not consistent with the established OntoUML 2.0 version that is used for modelling. Have you thought about upgrading to a newer version to make gUFO consistent with OntoUML 2.0 modeling? I think it could help a lot to use gUFO in practice. Some of the important relationships and stereotypes are missing from gUFO, and so it would be useful to add them.
The main changes would be:
1, Collective, Mode, Quality, Quantity and Relator would be separate stereotypes that are not subtypes of Kind and can have Role and Phase as subtypes.
2, Adding the Containment stereotype.
3, Adding the Derivation stereotype.
4, Mediation would be a separate stereotype.
5, Adding Composition and Aggregation.
I apologize if I missed something and some of these features are already included in gUFO, but I didn't find them.
Describe the solution you'd like
Upgrading to OntoUML 2.0 and adding missing stereotypes.
Is your feature request related to a problem? Please describe.
In order to separate the features
from bugs
you've already included two templates. We suggest to insert a third template to distinguish questions
from the other two.
Describe the solution you'd like
Please find below a YAML template for questions. Most importantly, it prepends "Question: " to the title. Some suggestions are made about formulating a proper question.
This because we anticipate many questions in our project.
Thanks in advance.
name: Question
description: File a question about the use of gUFO
title: "[Question]: your question here"
labels: ["question", "Q&A"]
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to ask a question about gUFO!
- type: textarea
id: question
attributes:
label: Specify your question
description: Please describe your question clearly: make assumptions explicit, quote the relevant sentence(s) from our documentation, structure the question by separating the What from the How.
placeholder: |
1. What do you want to achieve?
1. What model did you draft to try to achieve exactly that?
1. Where did you get stuck and why?
1. What knowledge do you lack to make progress?
1. What is your particular question you need answered? Avoid a yes/no question.
validations:
required: true
- type: textarea
id: example
attributes:
label: Insert an example
description: Please add any example code to exemplify your question. It will be turned into code automatically, so no need for backticks.
render: shell
validations:
required: false
Describe the bug
In the documentation, Aspect
s are considered Endurants. At the same time, the individuals they instantiate are considered to inhereIn ConcreteIndividuals
. The latter I concur, but the former is very confusing - at least for me. Particularly, according to the Taxonomy of Individuals gufo considers Quality
s to be Aspect
s . However, according to the ontological sextet below (adapted from [1]; part (a) adapted from [2]) Aspect
s (*) stand on themselves and characterise Endurants.
(*) Depicted above, in Figure (a), the Aspects are denoted in [1] as Quality Universals and in [2] as Moment Universals; I assume that these are more denotational differences whereas their meaning are equivalent over [1], [2] and gufo. If not, this could be the source of my confusion.
Expected behavior
I assume that in the Taxonomy of Individuals, one should consider Aspect
s at the same level as Endurant
s, Event
s and - possibly - Situation
s.
If I'm wrong in my conclusions, than I suggest to improve the documentation -- not being able to understand a text is considered a flaw of the text as opposed to an incapability of the reader 😉
References
In the gUFO documentation it says to prefer Relator to TemporaryRelationshipSituation in case of a MaterialRelationshipType. However most of the examples given of the TemporaryRelationshipSituation concern MaterialRelationshipTypes ("the situation in which Einstein works at the Swiss Patent Office in Bern; the situation in which Elon Musk studies at the University of Pennsylvania; the situation in which John Lennon is married to Yoko Ono" ). Could someone clarify?
The object property gufo:isDerivedFrom
has gufo:EndurantType
as its range.
That prevents us from representing that a historical relation is derived from an event.
For instance:
:wasWrittenBy rdf:type owl:ObjectProperty;
rdfs:subPropertyOf gufo:historicallyDependsOn ;
rdfs:domain :Book;
rdfs:range :Author;
gufo:isDerivedFrom :CompositionProcess .
:CompositionProcess rdfs:subClassOf gufo:Event .
Shouldn't we expand this range to also include gufo:Event
?
Maybe even make it gufo:ConcreteIndividual
This truthmaking pattern is discussed in:
Guarino, N., Sales, T. P., & Guizzardi, G. (2018, October). Reification and truthmaking patterns. In International Conference on Conceptual Modeling (pp. 151-165). Springer, Cham.
I have two questions about the gufo:RelationshipType:
According to the gufo-documentation "instances of gufo:Type are classes, and should specialize the taxonomy of individuals in gUFO". But how about the Relationshiptypes? Instances of these are properties instead of classes and don't specialize the taxonomy of individuals.
The domain of gufo:categorizes is (gufo:Type and not(gufo:AbstractIndividualType) and not(gufo:ConcreteIndividualType)). Why isn't gufo:RelationshipType excluded in the domain?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.