Presentation from the OntoCommons workshop, 31 Aug 2022, https://ontocommons.eu/news-events/events/workshop-ontology-engineering-and-knowledge-graphs-tool-ecosystem. Abstract: A dilemma of the early drafting phase of ontological modeling is whether to start with OWL-conformant structures (albeit nicely wrapped in graphs or constrained ‘natural language’) from the onset, or using purely informal representation means such as ad hoc diagrams and free text. We hypothesize that the former approach may lead to pre-mature, arbitrary fixing of one of several possible modeling variants for the same reality, while the latter often leaves too much ambiguity in the model. We propose, as a partial solution to the dilemma, the PURO modeling language and an associated toolset (in particular, a graph-based editor named PURO Modeler, see https://protegeserver.cz/purom5). The key principles of PURO are as follows: 1) modeling is carried out through a link-node diagram, which primarily expresses the instance (example) level, and then the type level as secondary; 2) the modeling allows for arbitrary meta-typing, relationship arity and meta-relationships. To bridge the gap between such a relatively unconstrained representation and computable ontological models, transformation patterns can be subsequently applied. Via the patterns, the user can semi-automatically generate alternative skeletons of models in the target language. The supported target languages are currently OWL and OntoUML. With respect to OWL, the alternative transformation patterns can produce ontologies biased towards, e.g., modeling universals exclusively as classes (as common in biomedicine) vs. meta-modeling them with individuals (as common in some other families of knowledge graphs), towards using object properties vs. data properties (the latter being frequent in e-commerce schemas), or towards reifying all relationships including the binary ones.

1. Ontology
drafting
in PURO
Vojtěch Svátek and Marek Dudáš
Prague University of Economics and
Business, CZ

2. Overcoming the blank canvas in OE
• Approach 1: Ad hoc diagrams and free text
• all conveniently informal, easy for domain experts
• … but then a big leap remains to an operational ontological representation
• … just as with relational DB (conceptual vs. logical model) – but shouldn’t the
graph nature of ontologies yield more?
• Approach 2: Graphical diagrams and/or controlled natural language
conformant to the target ontology language
• domain expert still shielded from the dismaying (e.g., OWL) code
• operational representation reached within a click
• … but isn’t it too early to freeze the representation structures?
• … there are so many alternatives of ontologically encoding the same reality!

3. Overcoming the blank canvas in OE
• Approach 1: Ad hoc diagrams and free text
• all conveniently informal, easy for domain experts
• … but then a big leap remains to an operational ontological representation
• … just as with relational DB (conceptual vs. logical model) – but shouldn’t the
graph nature of ontologies yield more?
• Approach 2: Graphical diagrams and/or controlled natural language
conformant to the target ontology language
• domain expert still shielded from the dismaying (e.g., OWL) code
• operational representation reached within a click
• … but isn’t it too early to freeze the representation structures?
• … there are so many alternatives of ontologically encoding the same reality!

4. Overcoming the blank canvas in OE
• Approach 1: Ad hoc diagrams and free text
• all conveniently informal, easy for domain experts
• … but then a big leap remains to an operational ontological representation
• … just as with relational DB (conceptual vs. logical model) – but shouldn’t the
graph nature of ontologies yield more?
• Approach 2: Graphical diagrams and/or controlled natural language
conformant to the target ontology language
• domain expert still shielded from the dismaying (e.g., OWL) code
• operational representation reached within a click
• … but isn’t it too early to freeze the representation structures?
• … there are so many alternatives of ontologically encoding the same reality!

5. Overcoming the blank canvas in OE
• Approach 1: Ad hoc diagrams and free text
• all conveniently informal, easy for domain experts
• … but then a big leap remains to an operational ontological representation
• … just as with relational DB (conceptual vs. logical model) – but shouldn’t the
graph nature of ontologies yield more?
• Approach 2: Graphical diagrams and/or controlled natural language
conformant to the target ontology language
• domain expert still shielded from the dismaying (e.g., OWL) code
• operational representation reached within a click
• … but isn’t it too early to freeze the representation structures?
• … there are so many alternatives of ontologically encoding the same reality!

6. Overcoming the blank canvas in OE
• Approach 1: Ad hoc diagrams and free text
• all conveniently informal, easy for domain experts
• … but then a big leap remains to an operational ontological representation
• … just as with relational DB (conceptual vs. logical model) – but shouldn’t the
graph nature of ontologies yield more?
• Approach 2: Graphical diagrams and/or controlled natural language
conformant to the target ontology language
• domain expert still shielded from the dismaying (e.g., OWL) code
• operational representation reached within a click
• … but isn’t it too early to freeze the representation structures?
• … there are so many alternatives of ontologically encoding the same reality!

7. Example of alternative encodings of reality
„Some papers get accepted
and some get rejected
by the PC Chair“

8. Example of alternative encodings of reality
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection
„Some papers get accepted
and some get rejected
by the PC Chair“

9. Example of alternative encodings of reality
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection
„Some papers get accepted
and some get rejected
by the PC Chair“

10. Example of alternative encodings of reality
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection
„Some papers get accepted
and some get rejected
by the PC Chair“

11. Example of alternative encodings of reality
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection
„Some papers get accepted
and some get rejected
by the PC Chair“

12. Example of alternative encodings of reality
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection
Distinction of paper acceptance
vs. rejection:
• Classes over papers
• Distinct object properties
• Distinct decision individuals
• Classes over chair’s decision

13. Example of alternative encodings of reality
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection
Distinction of paper acceptance
vs. rejection:
• Classes over papers
• Distinct object properties
• Distinct decision individuals
• Classes over chair’s decision
… never mind replacing the
object properties by datatype
ones, inverting their direction,
and a few other options…

14. Lesson learned
• There is already quite some complexity involved when deciding about the basic structures’, e.g., within the
RDF/S expressiveness … long before we have to think about complex OWL axioms or SHACL/ShEx constraints
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection

15. Lesson learned
• There is already quite some complexity involved when deciding about the basic structures’, e.g., within the
RDF/S expressiveness … long before we have to think about complex OWL axioms or SHACL/ShEx constraints
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection

16. Lesson learned
• There is already quite some complexity involved when deciding about the basic structures’, e.g., within the
RDF/S expressiveness … long before we have to think about complex OWL axioms or SHACL/ShEx constraints
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection

17. Lesson learned
• There is already quite some complexity involved when deciding about the basic structures’, e.g., within the
RDF/S expressiveness … long before we have to think about complex OWL axioms or SHACL/ShEx constraints
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection

18. Lesson learned
• There is already quite some complexity involved when deciding about the basic structures’, e.g., within the
RDF/S expressiveness … long before we have to think about complex OWL axioms or SHACL/ShEx constraints
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: (EquivalentTo {acceptance, rejection})
hasPCChairDecision Characteristics: FunctionalProperty
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection

19. Lesson learned
• There is already quite some complexity involved when deciding about the basic structures’, e.g., within the
RDF/S expressiveness … long before we have to think about complex OWL axioms or SHACL/ShEx constraints
PaperAcceptedByPCChair SubClassOf: Paper
PaperRejectedByPCChair SubClassOf: Paper
PaperAcceptedByPCChair DisjointWith: PaperRejectedByPCChair
accepts Domain: PCChair accepts Range: Paper
rejects Domain: PCChair rejects Range: Paper
accepts DisjointWith: rejects.
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision. Individual: acceptance Types: Decision Individual: rejection Types: …
hasPCChairDecision Characteristics: FunctionalProperty.
hasPCChairDecision Domain: Paper
hasPCChairDecision Range: Decision
Acceptance SubClassOf: Decision
Rejection SubClassOf: Decision
Acceptance DisjointWith: Rejection.

20. Possible desiderata for a drafting approach

21. Possible desiderata for a drafting approach
• Keep the door open for alternative encodings in the target language
• Thus allow to go ‘as close as possible’ to the original perception of reality,
without being constrained by computability constraints

22. Possible desiderata for a drafting approach
• Keep the door open for alternative encodings in the target language
• Thus allow to go ‘as close as possible’ to the original perception of reality,
without being constrained by computability constraints
• Use a modeling language with
• Relaxed rules for combining its primitives (see above)
• (A bit of) formal underpinning
• Graphical representation with a limited set of primitives

23. Possible desiderata for a drafting approach
• Keep the door open for alternative encodings in the target language
• Thus allow to go ‘as close as possible’ to the original perception of reality,
without being constrained by computability constraints
• Use a modeling language with
• Relaxed rules for combining its primitives (see above)
• (A bit of) formal underpinning
• Graphical representation with a limited set of primitives
• What else might help?
• Example-based approach – with sample instances gluing the whole model
together

24. We call the solution “PURO”
• “Puro” in the sense of allowing to keep the modeled reality free of
impurity incurred by language (decidability, etc.) constraints
• “PURO” is the essence of the ontological distinctions considered:
Particulars vs. Universals, and Relationships vs. Objects

25. We call the solution “PURO”
• “Puro” in the sense of allowing to keep the modeled reality free of
impurity incurred by language (decidability, etc.) constraints
• “PURO” is the essence of the ontological distinctions considered:
Particulars vs. Universals, and Relationships vs. Objects

26. PURO approach components
• Modeling language (+ its trivial „foundational ontology“)
• Modeling guidelines
• Tooling

27. PURO language primitives – graph nodes
• B-object
• particular
• B-type
• universal, having B-objects as instances
• but higher-order meta-types (having B-types as instances) allowed; stratification assumed
• B-relationship
• particular; with arbitrary arity
• B-relation
• universal, having B-relationships as instances
• B-valuation
• particular; assignment of quantitative value
• B-attribute
• universal, having B-valuations as instances
• Even B-relationships can be assigned B-valuations or participate in other B-relationships
Note: „B“ is a legacy symbol for „background“; we previously coined it to suggest that PURO allows to build „background“ models underlying
„foreground“ OWL ontologies

28. PURO language primitives – graph edges
• B-instanceOf
• B-subTypeOf
• Auxiliary labeled edges in relationships
The language has its (lightweight) FOL axiomatization
• currently being prepared for publication

30. Modeling guidelines
• Very rudimentary for the moment
• Foremost: rule in/out indicators for the main distinctions
• E.g.: „Does/can it have instances? Then it should be a B-type and not a B-
object.“
• Examples of other recommendations:
• B-objects should link (by B-instanceOf) to at least one B-type
• Identifiers shouldn’t be part of a PURO model (unless the domain of
identifiers proper is addressed)
• Use WH-terms for auxiliary edges in B-relationships if possible

31. Tooling
• Allows for
• PURO model visual authoring
• PURO model management (modularization and merging)
• PURO model transformation to OWL
• with different “encoding styles”
• with possible reuse of existing OWL entities
• PURO model transformation to OntoUML
• See the follow-up demo

32. Initial experiments with testing subjects
• Comparison of “PURO first, Protégé next” vs. „Protégé from start“
scenarios, when modeling the same textually described situation
• Performance mostly similar
• Model correctness mostly similar… but different kinds of errors!
• User satisfaction slightly lower for PURO – most likely due to the low maturity
of the tooling

33. Initial experiments with testing subjects
• Comparison of “PURO first, Protégé next” vs. „Protégé from start“
scenarios, when modeling the same textually described situation
• Performance mostly similar
• Model correctness mostly similar… but different kinds of errors!
• User satisfaction slightly lower for PURO – most likely due to the low maturity
of the tooling

34. Future work
• Still a long way to go till a cost-effective ontology drafting approach
• Probably most crucial:
• More systematic and intuitive PURO modeling guidelines
• Proven transformation patterns for generating OWL from PURO, aligned with
the needs of different communities and with the SotA in entity reuse
• In the meantime, PURO can serve as a tool for exploring ontological
modeling challenges: separating those related to the intricacies of
particular target language (such as OWL) from those related to
ontological conceptualization as such

35. Future work
• Still a long way to go till a cost-effective ontology drafting approach
• Probably most crucial:
• More systematic and intuitive PURO modeling guidelines
• Proven transformation patterns for generating OWL from PURO, aligned with
the needs of different communities and with the SotA in entity reuse
• In the meantime, PURO can serve as a tool for exploring ontological
modeling challenges: separating those related to the intricacies of
particular target language (such as OWL) from those related to
ontological conceptualization as such

36. PURO bibliography
• Marek Dudás, Daniel Bedrnícek, Vojtech Svátek: Module Merging in PURO Visual Modeling. In: ModularKnowledge@ESWC 2022:
152-158
• Vojtech Svátek, Ján Kluka, Miroslav Vacura, Martin Homola, Marek Dudás: Patterns for Referring to Multiple Indirectly Specified
Objects (MISO): Analysis and Guidelines. WOP (Book) 2021: 1-24
• Marek Dudás, Tomás Morkus, Vojtech Svátek, Tiago Prince Sales, Giancarlo Guizzardi: Kickstarting OntoUML Modeling from PURO
Instance-Level Examples. In: EKAW (Posters & Demos) 2020: 36-40
• Tomás Hanzal, Vojtech Svátek, Miroslav Vacura: Event Categories on the Semantic Web and Their Relationship/Object Distinction.
In: FOIS 2016: 183-196
• Marek Dudás, Vojtech Svátek, Miroslav Vacura, Ondrej Zamazal: Starting Ontology Development by Visually Modeling an Example
Situation - A User Study. In: VOILA@ISWC 2016: 114-119
• Marek Dudás, Ondrej Zamazal, Vojtech Svátek: Exploiting ontology matching to support reuse in PURO-started ontology
development. In: OM@ISWC 2016: 243-244
• Marek Dudás, Tomás Hanzal, Vojtech Svátek, Ondrej Zamazal: OBOWLMorph: Starting Ontology Development from PURO
Background Models. In: OWLED 2015: 14-20
• Marek Dudás, Tomás Hanzal, Vojtech Svátek, Ondrej Zamazal: OBM2OWL Patterns: Spotlight on OWL Modeling Versatility. In:
WOP 2015
• Marek Dudás, Tomás Hanzal, Vojtech Svátek: What Can the Ontology Describe? Visualizing Local Coverage in PURO Modeler. In:
VISUAL@EKAW 2014: 28-33
• Vojtech Svátek, Simone Serra, Miroslav Vacura, Martin Homola, Ján Kluka: B-Annot: Supplying Background Model Annotations for
Ontology Coherence Testing. In: WoDOOM 2014: 59-66
• Vojtech Svátek, Martin Homola, Ján Kluka, Miroslav Vacura: Mapping structural design patterns in OWL to ontological background
models. In: K-CAP 2013: 117-120
• Vojtech Svátek, Martin Homola, Ján Kluka, Miroslav Vacura: Metamodeling-Based Coherence Checking of OWL Vocabulary
Background Models. In: OWLED 2013

37. Credits
• Our colleagues in the PURO team:
• Miroslav Vacura (VSE, Prague), Martin Homola, Ján Kluka (UK, Bratislava)
• Alumni: Simone Serra, Tomáš Hanzal, Tomáš Morkus, Daniel Bedrníček
• Partially supported from projects/funders (2013-2021):
• EU FP7 LOD2 project, IGA VSE projects, CSF FCatPoWO project,
Czecho-Slovak LAAOS project