S·I·O·C

Building on the work of F·O·A·F and Awol, the Semantically‐Interlinked Online Communities vocabulary, or S·I·O·C, aims to provide a metadata model for the social internet. Unlike newer, more narrowly‐scoped vocabularies, S·I·O·C explicitly aimed to model everything from forums to microblogs to wikis to bookmarks collections to events calendars.

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 sioc:User class (use User Account instead).

  • The sioc:Role class, and related properties sioc:has_function, sioc:has_scope, sioc:function_of, and sioc:scope_of. Roles, modelled in this way, are not actually very useful, because each one must be highly context‐specific and it is difficult for them to share features. A better modelling approach would be to use a qualified belongingness relation between User Accounts (or other entities) and the things they belong to, and on that qualified relation indicate qualities such as roles. This would enable the roles themselves to be modelled in a context‐independent manner.

  • The sioc:embeds_knowledge property, which is needlessly formal.

  • The sioc:link property, which has unclear utility. Consider has link instead, or just use ordinary R·D·F named node functionality.

  • The sioc:next_by_date and sioc:previous_by_date properties, which are intended to allow iterating over the Items in a Container. These properties fail to be usable when an Item belongs to multiple Containers at the same time.

  • The sioc:shared_by and sioc:sibling properties, which are underspecified and probably an inadequate model. If a share is simply a kind of event, it would be better to use an event‐based model here; if shares result in the creation of new resources, it would be best to signify the sharer as the creator of the new resource, while linking back to the original.

  • The sioc:email_sha1 property, whose primary utility (matching things to known contacts) is currently out‐of‐scope for this ontology.

  • The sioc:id property, because S·I·O·C makes restrictions which are difficult to practically assess. Specifically, it is required that these be identifiers which are unique to a Site, but there is no mechanism for actually associating them with the Sites that they are identifiers for (an Item may belong to multiple Sites). To record an identifier without the presumption of uniqueness, identifier is available. If per‐Site uniqueness is needed, qualifying either the belongingness relationship or the identifier itself (perhaps using has identifier) is necessary to indicate the relationship between the identifier and Site.

  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 User Account to Social Entity.

• 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 Status and has status, which are potentially useful and adopted here.

• The S·I·O·C Actions ontology is a bit buggy, but makes an attempt at modelling technological processes thru its Action class. This is a weaker form of provenance event information than can be modelled with, for example, Prov·O, but it may still be useful, so this ontology defines the terms.

• 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 Category and Tag classes are broadly‐applicable and defined here. The remaining types are of more dubious utility, but are generally harmless and have been defined for completeness, with the following exceptions :⁠—

  • sioctypes:ArgumentativeDiscussion, for the same reasons the S·I·O·C Argument ontology is excluded.

  • sioctypes:ProjectDirectory, which is defined as a Collection, because it is unclear what kinds of Items it is meant to contain.

• 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.