The IBIS (bis) Vocabulary

Author
Dorian Taylor
Version
0.4
Created
December 11, 2012
Updated
December 12, 2012
February 24, 2014
February 22, 2018
March 24, 2019
Namespace URI
https://privatealpha.com/ontology/ibis/1#
Preferred Namespace Prefix
ibis

This document specifies a vocabulary for describing an IBIS (issue-based information system).

The purpose of this vocabulary is to express the necessary semantics for the internal representation of—and interchange between—collaborative software systems that facilitate structured argumentation and issue-based reasoning. This vocabulary augments the semantic elements of the gIBIS paper by reusing components from, and thus integrating it into the Semantic Web.

This document was inspired by work from Danny Ayers, which, as of around October of 2012, has unfortunately disappeared from the web. I developed this vocabulary to supplant the original after several attempts to reach Mr. Ayers. It differs from the Ayers version primarily in that it is an extension of SKOS, due to the suitability of the Concept as a common ancestor for expressing the fundamental IBIS types.

As with the other vocabularies on this site, this prose version is canonical, and the RDF/XML and N3/Turtle versions are derived from it.

Classes

Issue

An Issue is a state of affairs, claimed by one or more Agents to either be a misfit itself, or affecting some other Issue or Position.

Subclass of:
skos:Concept
Property restrictions:
skos:narrowerTransitiveibis:Issue
skos:broaderTransitiveibis:Issue
ibis:replacesibis:Issue
ibis:replaced-byibis:Issue
Disjoint with:
ibis:Position

Back to Top

Position

A Position asserts a moral, ethical, pragmatic, or similar kind of assertion, typically identifying what, if anything, should be done about an Issue.

Subclass of:
skos:Concept
Property restrictions:
skos:narrowerTransitiveibis:Position
skos:broaderTransitiveibis:Position
ibis:replacesibis:Position
ibis:replaced-byibis:Position
Disjoint with:
ibis:Issue
ibis:Argument

Back to Top

Argument

An Argument is a type of Issue that explicitly supports or refutes a Position.

An Argument need not only relate in scope to another Argument, but it must only be replaced by another argument.

Subclass of:
ibis:Issue
Property restrictions:
ibis:replacesibis:Argument
ibis:replaced-byibis:Argument
Disjoint with:
ibis:Position

Back to Top

Invariant

An Issue or Position can be marked Invariant to denote that it has been deemed outside of the influence of the Agents in the system, i.e., something to be steered around.

Subclass of:
skos:Concept

Back to Top

Network

A network of issues, positions, and arguments.

Subclass of:
skos:ConceptScheme

Back to Top

Properties

Agency

Since argumentation doesn't happen in a vacuum, it is important to provide a mechanism for connecting agents (ideally people) to the process. While the Dublin Core and provenance ontologies are available for expressing authorship, there exist other agent-related considerations.

These terms are extensions to the original IBIS model.

endorses

An Agent can endorse a concept without having initially mentioned or advanced it, and without any additional comment.

This term, along with ibis:endorsed-by, enables an Agent to signal its agreement with a concept. To signal disagreement, explain why with an ibis:Argument that ibis:opposes the concept.

Domain:
foaf:Agent
Range:
skos:Concept
Inverse of:
ibis:endorsed-by

Back to Top

endorsed by

A concept can be endorsed by an Agent without said Agent having mentioned or advanced it initially, and without any additional comment.

This term, along with ibis:endorses, enables an Agent to signal its agreement with a concept. To signal disagreement, explain why with an ibis:Argument that ibis:opposes the concept.

Domain:
skos:Concept
Range:
foaf:Agent
Inverse of:
ibis:endorses

Back to Top

concerns

The subject is an issue concerning the object, which can be any resource.

Domain:
ibis:Issue
Range:
owl:Thing
Inverse of:
ibis:concern-of

Back to Top

concern-of

The subject is an issue concerning the object, which can be any resource.

Domain:
owl:Thing
Range:
ibis:Issue
Inverse of:
ibis:concerns

Back to Top

Subordination and Superordination

While all IBIS terms inherit the semantic relations from SKOS, the IBIS paper specifies mereological relations peculiar to Issues. I have relaxed the constraint specified in the paper, such that these relations are now merely vestigial.

specializes

The subject is a more specific form of the object.

The equivalent property skos:broader asserts that the object is broader than the subject, while the subject of ibis:specializes is more specific than the object.

Equivalent property:
skos:broader
Inverse of:
ibis:generalizes

Back to Top

generalizes

The subject is a more generic form of the object.

The equivalent property skos:narrower asserts that the object is narrower than the subject, while the subject of ibis:generalizes is more general than the object.

Equivalent property:
skos:narrower
Inverse of:
ibis:specializes

Back to Top

Replacement

replaces

Indicates when a concept replaces another concept of the same type.

Domain:
skos:Concept
Range:
skos:Concept
Sub-property of:
dct:replaces
Inverse of:
ibis:replaced-by

Back to Top

replaced by

Indicates when a concept is replaced by another concept of the same type.

Domain:
skos:Concept
Range:
skos:Concept
Sub-property of:
dct:isReplacedBy
Inverse of:
ibis:replaces

Back to Top

Questions

questions

Indicates an issue that raises doubt on a belief.

Domain:
ibis:Issue
Range:
skos:Concept
Sub-property of:
ibis:suggested-by
Inverse of:
ibis:questioned-by

Back to Top

questioned by

Indicates a belief called into question by an issue.

Domain:
skos:Concept
Range:
ibis:Issue
Sub-property of:
ibis:suggests
Inverse of:
ibis:questions

Back to Top

Suggestions

suggests

Indicates when the subject belief suggests the object issue.

Domain:
skos:Concept
Range:
ibis:Issue
Inverse of:
ibis:suggested-by

Back to Top

suggested by

Indicates when the subject issue is suggested by the object belief.

Domain:
ibis:Issue
Range:
skos:Concept
Inverse of:
ibis:suggests

Back to Top

Response

response

Indicates a position that responds to the subject issue.

Domain:
ibis:Issue
Range:
ibis:Position
Inverse of:
ibis:responds-to

Back to Top

responds to

Indicates an issue to which the subject position responds.

Domain:
ibis:Position
Range:
ibis:Issue
Inverse of:
ibis:response

Back to Top

Argumentation

supports

Indicates a subject argument that supports an object position.

Domain:
ibis:Argument
Range:
ibis:Position
Inverse of:
ibis:supported-by

Back to Top

supported by

Indicates a subject position supported by an object argument.

Domain:
ibis:Position
Range:
ibis:Argument
Inverse of:
ibis:supports

Back to Top

opposes

Indicates a subject argument that opposes an object position.

Domain:
ibis:Argument
Range:
ibis:Position
Inverse of:
ibis:opposed-by

Back to Top

opposed by

Indicates a subject position opposed by an object argument.

Domain:
ibis:Position
Range:
ibis:Argument
Inverse of:
ibis:opposes

Back to Top

Revisions

The initial version of this vocabulary was adapted directly from the gIBIS paper and implemented as a Web application. It was immediately evident through use that it made little sense that an Argument was something disjoint from an Issue, both from a semantic perspective, and from the perspective of implementing the user interface. It made more sense, therefore, to make Argument a subclass of Issue.

It also made sense to provide a mechanism to indicate the negotiability of an Issue or a Position. For instance, we can imagine an Issue (or Argument) like The QWERTY keyboard is a ubiquitously familiar interface. Consider also a Position expressing a standing policy prescription, like Never appease a tyrant. In both these cases, it is useful to mark them as Invariant, which we do by decorating them with the Invariant class.

I initially created the generalizes, specializes, replaces, and replaced-by predicates to correspond to the paper, but again, through use, it became evident that the constraint that only an Issue could make use of them made little sense.

Without this constraint, the generalizes/specializes pair are redundant versus their super-properties, skos:narrower and skos:broader. I'm keeping them around, though, as equivalent properties, because of the lexical ambiguity in the SKOS terms. I also added same-class constraints, but against skos:broaderTransitive and skos:narrowerTransitive to reintroduce the potential for transitivity.

I decided to retain replaces and replaced-by as sub-properties of their Dublin Core counterparts, though only to reinforce them as object properties over the domain and range of skos:Concept.

After enough time in the saddle, I am fairly convinced that questions and suggests are roughly inversely related, with questions being a stronger form of suggested-by, and have such made the former a subproperty of the latter.

Future Directions

Other IBIS implementations have an explicit concept of a Question, which I considered but ultimately left out. There is already a discontinuity between the grammatical form of a question and its purpose in ordinary dialogue—i.e., are we actually asking for information or is the question merely rhetorical. We don't need to confuse things further by cementing that discontinuity into formal language.

There is also the natural tendency that once we have agreed on a particular Position, that we commit it to action. It is therefore tempting to extend the IBIS vocabulary into some sort of project planning apparatus. I have chosen instead to leave this vocabulary alone if possible, and extend it through a process model ontology.

References