nemo-ufes / gufo Goto Github PK

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)

1. 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?

2. 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?

Model

: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:

1. A Person was involved in an Accident as the Driver (Role of Person) of a certain Car.
2. The box contains 20 phones" (i.e. Container contains Amount of Objects)?

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:

• E.g. two witnesses giving different accounts of the same event.
• E.g. a cop suspecting that a crime 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:

1. improve the documentation, making clear this intended use, and
2. create a partition set (owl:disjointUnionOf) for the non-leaf classes that still don't have it in the types hierarchy. For the Endurant types, the classes are:

• AntiRigidType
• SemiRigidType
• NonSortal
• RigidType
• Sortal

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:

• concernsConstitutedEndurant
• concernsTemporaryWhole
• constitutes
• isAspectProperPartOf
• isComponentOf
• isEventProperPartOf
• isObjectProperPartOf
• isProperPartOf
• isSituationProperPartOf
• gufo:isSubQuantityOf
• standsInQualifiedConstitution
• standsInQualifiedParthood

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:

• Mode, which is mapped to GUFO's Intrinsic Mode, and
• Collective, which is mapped to GUFO's Collection.

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, Aspects 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 Qualitys to be Aspects . However, according to the ontological sextet below (adapted from [1]; part (a) adapted from [2]) Aspects (*) 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 Aspects at the same level as Endurants, Events and - possibly - Situations.

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

1. B. Smith, “Against fantology,” in Experience and Analysis, J. C.Marek and M. E. Reicher, Eds. HPT&ÖBV, 2005, pp. 153–170
2. G. M. Miranda, J. P. A. Almeida, G. Guizzardi and C. L. B. Azevedo, "Foundational Choices in Enterprise Architecture: The Case of Capability in Defense Frameworks," 2019

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:

1. 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.

2. 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?