https://vocab.methodandstructure.com/ibis#ibisThis 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 replace it. 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.
Entityibis:Entity is the abstract superclass of from which the more specific entities are derived.
skos:ConceptStateA State can be understood as a snapshot of a system at a given time, such as before or after an event.
ibis:EntityIssueAn 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.
ibis:Stateskos:narrowerTransitive ∈ ibis:Issue
skos:broaderTransitive ∈ ibis:Issue
ibis:replaces ∈ ibis:Issue
ibis:replaced-by ∈ ibis:Issue
ibis:PositionPositionA Position asserts a moral, ethical, pragmatic, or similar kind of assertion, typically identifying what, if anything, should be done about an Issue.
ibis:Entityskos:narrowerTransitive ∈ ibis:Position
skos:broaderTransitive ∈ ibis:Position
ibis:replaces ∈ ibis:Position
ibis:replaced-by ∈ ibis:Position
ibis:Issueibis:ArgumentArgumentAn Argument is a type of Issue that explicitly supports or refutes a Position.
ibis:Issueibis:replaces ∈ ibis:Argument
ibis:replaced-by ∈ ibis:Argument
ibis:PositionInvariantAn ibis:Entity can be marked ibis: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.
ibis:EntityNetworkA network of issues, positions, and arguments.
skos:ConceptSchemeSince 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.
endorsesAn Agent can endorse a concept without having initially mentioned or advanced it, and without any additional comment.
foaf:Agentibis:Entityibis:endorsed-byendorsed byA concept can be endorsed by an Agent without said Agent having mentioned or advanced it initially, and without any additional comment.
ibis:Entityfoaf:Agentibis:endorsesThis IBIS vocabulary is based on SKOS, and therefore has a close relationship with it. These properties connect IBIS to with skos
concernsThe subject is an issue concerning the object, which can be any resource.
ibis:Entityibis:concern-ofconcern-ofThe subject is an issue concerning the object, which can be any resource.
ibis:Entityibis:concernsWhile 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.
generalizesThe subject is a more generic form of the object.
ibis:Entityibis:Entityskos:narroweribis:specializesspecializesThe subject is a more specific form of the object.
ibis:Entityibis:Entityskos:broaderibis:generalizesreplacesIndicates when a concept replaces another concept of the same type.
ibis:Entityibis:Entitydct:replacesskos:semanticRelationibis:replaced-byreplaced-byIndicates when a concept is replaced by another concept of the same type.
ibis:Entityibis:Entitydct:isReplacedByskos:semanticRelationibis:replacesimpliesThe existence of an ibis:Entity implies an ibis:State.
ibis:Entityibis:Stateskos:semanticRelationibis:implied-byimplied-byAn ibis:State may be implied by an ibis:Entity.
ibis:Stateibis:Entityskos:semanticRelationibis:impliessuggestsAn ibis:Entity may suggest an ibis:Issue.
ibis:Entityibis:Issueibis:impliesibis:suggested-bysuggested-byAn ibis:Issue may be suggested by an ibis:Entity.
ibis:Issueibis:Entityibis:implied-byibis:suggestsquestionsIndicates an issue that raises doubt on a belief.
ibis:Issueibis:Entityibis:suggested-byibis:questioned-byquestioned-byIndicates a belief called into question by an issue.
ibis:Entityibis:Issueibis:suggestsibis:questionsresponseIndicates a position that responds to the subject issue.
ibis:Issueibis:Positionskos:semanticRelationibis:responds-toresponds-toIndicates an issue to which the subject position responds.
ibis:Positionibis:Issueskos:semanticRelationibis:responsesupportsIndicates a subject argument that supports an object position.
ibis:Argumentibis:Positionibis:suggested-byibis:supported-bysupported-byIndicates a subject position supported by an object argument.
ibis:Positionibis:Argumentibis:suggestsibis:supportsopposesIndicates a subject argument that opposes an object position.
ibis:Argumentibis:Positionibis:suggested-byibis:opposed-byopposed-byIndicates a subject position opposed by an object argument.
ibis:Positionibis:Argumentibis:suggestsibis:opposesThe 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.
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.