Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

💡 Top level concepts / structuring voc4cat #48

Open
dalito opened this issue Feb 13, 2024 · 14 comments · Fixed by #88
Open

💡 Top level concepts / structuring voc4cat #48

dalito opened this issue Feb 13, 2024 · 14 comments · Fixed by #88
Labels
discussion This needs more discussion documentation Improvements or additions to documentation
Milestone

Comments

@dalito
Copy link
Member

dalito commented Feb 13, 2024

Guideline for Hierarchies in Voc4Cat

first draft 2023-11-23

Voc4Cat is a taxonomy that organizes concepts by subject. The type of relations between concepts to create hierarchies are strictly Is-A relationships which are expressed by skos:broader and skos:narrower. Thus, voc4cat focuses on categorizing things by what they are. Such so called subject hierarchies with Is-A based hierarchies correspond well with ontological modelling and reasoning as well as semantic search or AI applications.

In contrast, topic hierarchies organize concepts for search, e.g. they might be organized based on what people are reminded on when hearing a term or what they associate with it. Topic hierarchies conflict with ontological modelling.

However, for use cases like e.g. selection lists in UIs grouping concepts by topic is valuable. In voc4cat, skos:collection may be used to create such lists or even list-of-lists. In this topic-wise form of organization part-of-relations or even looser relations (e.g. skos:related) dominate.

It is important to be aware of the differences between subject and topic hierarchies. Here are two examples to make the difference clear. The first organizes the hierarchy by topic (here part-of-relations):

  • Chemical Process
    • Reactor Unit
      • Catalyst Bed
    • Distillation Unit
    • Recycle Compressor

However, in voc4cat we want to create hierarchies based on "Is-A" relations as shown in the 2nd example:

  • Process
    • Manufacturing Process
      • Chemical Process
        • Catalytic Process

Here are the top level concepts that we propose to add soon:

  • physical object Entity with a concrete and physical nature.
  • abstract entity Any Entity that cannot be located in space-time. E.g. mathematical entities: formal semantics elements, regions within dimensional spaces, ideas, models,…
  • temporal entity Temporal entity includes anything that has a temporal dimension, whether it's an instantaneous point in time, a duration, or a sequence of events.
    • event An occurrence or happening, marked by a specific point in time. Events can be observed, recorded, and may have an impact on the state of the system or entities involved.
    • action Temporal entity that has a duration and occurs at specific points in time.
    • process A series of temporal entities like actions, events, changes, or functions that are not isolated but rather a connected sequences of activities. Processes often involve the transformation of inputs into outputs and can be conceptualized as workflows.
  • attribute An attribute is a characteristic of an entity that is intrinsic to and cannot exist without the entity. (properties, characteristics, qualities of things, states,...)

Related: #33

@dalito dalito added documentation Improvements or additions to documentation discussion This needs more discussion labels Feb 13, 2024
@dalito
Copy link
Member Author

dalito commented Feb 13, 2024

@nmoust @markdoerr @HendrikBorgelt @schumannj @AleSteB - Feedback welcome!

We tested this proposal with the existing terms and it is unambiguous and straight-forward to apply. The top concepts are similar to those in top-level ontologies (BFO, SIO, DOLCE), to what is proposed in ANSI/NISO Z39.19-2005 or what was proposed as minimal set of terms for agrovoc (which has too many top-level concept). So It should be a safe bet.

@dalito dalito added this to the 2024-rel1 milestone Feb 13, 2024
@markdoerr
Copy link

Hi @dalito,
thanks for the hierarchy proposal.
We should clarify some terms here:

  1. I would define physical object as an object in space-time with a mass (general matter / material)
  2. temporal entities, like events, actions and processes are still abstract entities, they have no perceivable representation in space-time (=they are immaterial), therefore they should be narrower concept of an abstract entity

@markdoerr
Copy link

.. and the same holds true for attributes they are also abstract / immaterial

@nmoust
Copy link
Collaborator

nmoust commented Feb 20, 2024

Dear @markdoerr ,

thank you for the feedback. So if I understood correctly you suggest that we change the structure to:

  1. Entities
  2. Physical objects
  3. Abstract entities
    3.1. Temporal entities
    3.1.1 Events
    3.1.2 Actions
    3.1.3 Processes
    3.2. Attributes

And change the definition of Physical object from "Entity with a concrete and physical nature." to "Object in space-time with a mass".

After discussing with @dalito , we can think of using the following structure:

  1. Physical entity
  2. Non temporal abstract entity
  3. Temporal abstract entity
    3.1 Events
    3.2 Actions
    3.3 Processes
  4. Attributes

Maybe this offers a simple structure easy (or easier) for the user to understand.

@markdoerr
Copy link

@nmoust and @dalito,
yes, I had exactly the first structure in mind, because it generates a logic hierarchy of "Things or Entities", based on their "abstractness". In your proposal it is unclear, why you put Attributes next to physical entities and (non-)temporal entities (so the ordering principle is not obvious).

@dalito
Copy link
Member Author

dalito commented Feb 20, 2024

Def. of "Attributes": An attribute is a characteristic of an entity that is intrinsic to and cannot exist without the entity. (added also to starting message which had no def before)

Informed by: http://www.w3.org/ns/ssn/Property, http://semanticscience.org/resource/SIO_000614

@schumannj
Copy link
Contributor

I am not sure I understand the difference between Attribute and Non temporal abstract entity correctly. E.g Selectivity, is it an attribute of a product in a chemical conversion (under specific conditions with a certain catalyst)? Is "reaction mechanism" or "chemical reaction network" a Non temporal abstract entity?
However a "chemical reaction" or "chemical conversion" would be a temporal abstract entity (process)? And the conversion of a reactant would again be an attribute? Is this right?

@schumannj
Copy link
Contributor

I believe in NOMAD the temporal abstract entities are called activity, and furthermore distiguished into process, measurement and analysis. I am not sure what would be the distinction between 3.1(Event), 3.2 (Action) and 3.3(Process) above or if they can be directly mapped.

@dalito
Copy link
Member Author

dalito commented Feb 21, 2024

@schumannj Thanks for feedback!

However a "chemical reaction" or "chemical conversion" would be a temporal abstract entity (process)? And the conversion of a reactant would again be an attribute? Is this right?

Yes.

Regarding activity/process: It comes down to exact definitions but both terms can work in my opinion (we can add a mapping to the nomad-def if it can be referenced by IRI).

We can also add more structure later. But in SKOS we don't want to (and can't) define a full ontological model but just structure terms that are then re-used in data models.

@richardlenz
Copy link

"The type of relations between concepts to create hierarchies are strictly Is-A relationships which are expressed by skos:broader and skos:narrower" -
skos:broader / skos:narrower does not refer to strict IS-A hierarchies - Instead these relations subsume a variety of hierarchical relationships including IS-A (which is the class-sublass relationship)
A strict IS-A hierarchy could be expressed by rdfs:subClassOf

@dalito
Copy link
Member Author

dalito commented Feb 23, 2024

@richardlenz thanks for the comment! "skos:broader / skos:narrower does not refer to strict IS-A hierarchies" - Yes, exactly. SKOS does not restrict the use to IS-A. In principle, one can create any kind of "hierarchy mess" via broader/narrower without violating any rule.

So the above should be seen as a guidance principle for our vocabulary. If this is followed well, re-using voc4cat in ontologies should be easier than if we have no guidance principle.

@richardlenz
Copy link

@dalito > .. "So the above should be seen as a guidance principle for our vocabulary. If this is followed well, re-using voc4cat in ontologies should be easier than if we have no guidance principle."

Thats true, but the purpose of a SKOS Vocabulary is to increase findability of terms by including vague relations of terms rather than limiting the hierarchy to strict class-subclass relations. (Otherwise these vague relations would be lost.). It is true that this does not allow for set based inference, but this is not the purpose of SKOS, and an inference engine would not interpret skos:narrower as a subclass relationship anyway. So therefore I would recommend to be aware of this distinction and simply add rdfs:subClassOf relationships where this actually holds. Alternatively, proper subclass relationships could actually be modelled as such an then the skos:narrower relationship can be inferred from that.

@RoteKekse
Copy link
Contributor

hey all, i am contemplating continuing contributing voc4cat but i saw that thephotocatalysis part is not obying the srict is a relation right now. so i am a bit unsure on how to evaluate what is there already and what not. is it planned to correct the hierachy?

@dalito
Copy link
Member Author

dalito commented May 7, 2024

Yes, as you observed some photo catalysis term hierarchies are not yet fully aligned with the approach suggested here. We still have the plan to fix this. Probably as part of a PR that adds the top level concepts.

@dalito dalito linked a pull request Aug 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This needs more discussion documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants