Building on the work of
Understanding that not every application would necessarily need to understand all of the terms that S·I·O·C provided, it was split into several modules, each with a different name·space. The list of modules is as follows :—
The S·I·O·C Core ontology defines all of the core terms of the S·I·O·C model. This ontology includes all of S·I·O·C Core, except for :—
The deprecated
The
The
The
The
The
The
The
S·I·O·C follows the undesirable pattern of defining many of its properties with a definite domain or range, typically of Item. This pattern exists for human benefit: The S·I·O·C documentation links classes to properties which have them in their domains or ranges, so defining such makes the intended usages of the properties more visible. However, from a modelling standpoint, it severely restricts the utility of the properties. This ontology removes domain and range restrictions when they serve no obvious benefit, so that properties such as addressed to may be used with things even when they are not a data‐backed Item.
Following a similar rationale to the above, this ontology loosens the domains and ranges of many properties from
The S·I·O·C Access ontology attempts to model access controls, but is small and feels incomplete in its current form.
It does, however, define
The S·I·O·C Actions ontology is a bit buggy, but makes an attempt at modelling technological processes thru its
The S·I·O·C Argument ontology attempts to model “issue‐based information systems”. It is overly formal (and specialized) for the purposes of this ontology, which has no allegiances to the issue‐based information system model, so its terms are ignored.
The S·I·O·C~Nepomuk ontology provides preliminary mappings to the Nepomuk vocabularies but doesn¦t define any useful terms of its own. This ontology will define its own mappings, should they be necessary (at present, Nepomuk is out‐of‐scope).
The S·I·O·C Quotes ontology defines a mechanism for modelling quotes alongside their responses. Altho this idea has potential, the modelling decisions are a bit confusing: Quotes and responses are both modelled as Items, but the combination of a quote and its response (a “block”) is itself an Item—is the relationship between blocks and their associated quotes and responses a membership relation, a link, or what? One would expect blocks to either be Containers with quote and response Item members (probably undesirable), or as Items whose quote and response are modelled thru some different mechanism.
Because of the weaknesses in this model, this ontology refrains from defining the corresponding terms.
The S·I·O·C Services ontology provides terms for modelling Web services and their endpoints. There isn¦t anything expressly wrong with this vocabulary, but modelling services, protocols, and endpoints is currently out of scope for this ontology, so its terms are ignored.
The S·I·O·C~Swan ontology defines mappings to the Semantic Web Applications in Neuromedicine vocabulary (Swan). It provides one additional term for online journals, which this ontology does not adopt.
The S·I·O·C Types ontology defines a number of classes for specifying specific types of resources.
The
The Sioc Wikitalk ontology is something of an attempt to model the way discussion and decisionmaking happens in wikispaces like those run by Wikimedia Foundation. This ontology has no investment in this model and considers modelling it to be out of scope.