If you could ‘mail order’ a language for representing ontologies or fancy knowledge graphs, what features would you want it to have? Or, from an artefact development viewpoint: what requirements would it have to meet? Perhaps it may not be a ‘Christmas wish list’ in these days, but a COVID-19 lockdown ‘keep dreaming’ one instead, although perhaps it may even be feasible to realise if you don’t ask for too much. Either way, answering this on the spot may not be easy, and possibly incomplete. Therefore, I have created a sample catalogue, based on the published list of requirements and goals for OWL and CL, and I added a few more. The possible requirements to choose from currently are loosely structured into six groups: expressiveness/constructs/modelling features; features of the language as a whole; usability by a computer; usability for modelling by humans; interaction with ‘outside’, i.e., other languages and systems; and ontological decisions. If you think the current draft catalogue should be extended, please leave a comment on this post or contact the author, and I’ll update accordingly.
E-1 Equipped with basic language elements: predicates (1, 2, n-ary), classes, roles, properties, data-types, individuals, … [select or add as appropriate].
E-2 Equipped with language features/constraints/constructs: domain/range axioms, equality (for classes, for individuals), cardinality constraints, transitivity, … [select or add as appropriate].
E-3 Sufficiently expressive to express various commonly used ‘syntactic sugarings’ for logical forms or commonly used patterns of logical sentences.
E-4 Such that any assumptions about logical relationships between different expressions can be expressed in the logic directly.
Features of the language as a whole
F-1 It has to cater for meta-data; e.g., author, release notes, release date, copyright, … [select or add as appropriate].
F-2 An ontology represented in the language may change over time and it should be possible to track that.
F-3 Provide a general-purpose syntax for communicating logical expressions.
F-4 Unambiguous, i.e., not needed to have negotiation about syntactic roles of symbols, or translations between syntactic roles.
F-5 Such that every name has the same logical meaning at every node of the network.
F-6 Such that it is possible to refer to a local universe of discourse (roughly: a module).
F-7 Such that it is possible to relate the ontology to other such universes of discourse.
F-8 Specified with a particular semantics.
F-9 Should not make arbitrary assumptions about semantics.
F-10 Cater for internationalization (e.g., language tags, additional language model).
F-11 Extendable (e.g., regarding adding more axioms to same ontology, add more vocabulary, and/or in the sense of importing other ontologies).
F-12 Balance expressivity and complexity (e.g., for scalable applications, for decidable automated reasoning tasks).
F-13 Have a query language for the ontology.
F-14 Declared with Closed World Assumption.
F-15 Declared with Open World Assumption.
F-16 Use Unique Name Assumption.
F-17 Do not use Unique Name Assumption.
F-18 Ability to modify the language with the language features.
F-19 Ability to plug in language feature extensions; e.g., ‘loading’ a module for a temporal extension.
Usability by computer
UC-1 Be an (identifiable) object on the Web.
UC-2 Be usable on the Web.
UC-3 Using URIs and URI references that should be usable as names in the language.
UC-4 Using URIs to give names to expressions and sets of expressions, in order to facilitate Web operations such as retrieval, importation and cross reference.
UC-5 Have a serialisation in [XML/JSON/…] syntax.
UC-6 Have symbol support for the syntax in LaTeX/…
UC-7 Such that the same entailments are supported, everywhere on the network of ontologies.
UC-8 Able to be used by tools that can do subsumption reasoning/taxonomic classification.
UC-9 Able to be used by tools that can detect inconsistency.
UC-10 Possible to read and write in the document with simple tools, such as a text editor.
UC-11 Unabiguous and simple grammar to ensure parsing documents as simple as possible.
Usability & modelling by humans
HU-1 Easy to use
HU-2 Have at least one compact, human-readable syntax defined which can be used to express the entire language
HU-3 Have at least one compact, human-readable syntax defined so that it can be easily typed up in emails
HU-4 Such that no agent should be able to limit the ability of another agent to refer to any entity or to make assertions about any entity
HU-5 Such that a modeller is free to invent new names and use them in published content.
HU-6 Have clearly definined syntactic sugar, such as a controlled natural language for authoring or rendering the ontology or an exhaustive diagramamtic notation
Interaction with outside
I-1 Shareable (e.g., on paper, on the computer, concurrent access)
I-2 Interoperable (with what?)
I-3 Compatible with existing standards (e.g., RDF, OWL, XML, URIs, Unicode)
I-4 Support an open networks of ontologies
I-5 Possible to import ontologies (theories, files)
I-6 Option ot declare inter-ontology assertions
O-1 3-Dimensionalist commitment, where entities are in space but one doesn’t care about time
O-2 3-Dimensionalist with a temporal extension
O-3 4-Dimensionalist commitment, where entities are in spacetime
O-4 Standard view of relations and relationships (there is an order in which the entities participare)
O-5 Positionalist relations and relationships (there’s no order, but entities play a role in the relation/relationship)
O-6 Have additional primitives, such as for subsumption, parthood, collective, stuff, sortal, anti-rigid entities, … [select or add as appropriate]
O-7 Statements are either true or false
O-8 Statements may vague or uncertain; e.g., fuzzy, rough, probabilistic [select as appropriate]
O-9 There should be a clear separation between natural language and ontology
O-10 Ontology and natural language are intertwined
That’s all, for now.