--- /dev/null
+<?xml version="1.0"?>
+<!--
+SPDX-FileCopyrightText: 2025 Lady <https://www.ladys.computer/about/#lady>
+SPDX-License-Identifier: CC0-1.0
+-->
+<!DOCTYPE NamedIndividual SYSTEM "../../DTD">
+<NamedIndividual name="http://rdfs.org/sioc/spec/">
+ <label xml:lang="en">S·I·O·C</label>
+ <comment xml:lang="en">
+ <p>
+ Building on the work of <ptr target="(FOAF)"/> and <ptr target="(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.
+ </p>
+ <p>
+ 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 :—
+ </p>
+ <list>
+ <item>
+ <p>
+ <strong>The S·I·O·C Core ontology</strong> 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 :—
+ </p>
+ <list>
+ <item>
+ <p>
+ The deprecated <resource name="sioc:User"/> class (use <ptr target="sioc:UserAccount"/> instead).
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="sioc:Role"/> class, and related properties <resource name="sioc:has_function"/>, <resource name="sioc:has_scope"/>, <resource name="sioc:function_of"/>, and <resource name="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 <ref target="sioc:UserAccount">User Accounts</ref> (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.
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="sioc:embeds_knowledge"/> property, which is needlessly formal.
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="sioc:link"/> property, which has unclear utility.
+ Consider <ptr target="awol:link"/> instead, or just use ordinary R·D·F named node functionality.
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="sioc:next_by_date"/> and <resource name="sioc:previous_by_date"/> properties, which are intended to allow iterating over the <ref target="sioc:Item">Items</ref> in a <ref target="sioc:Container">Container</ref>.
+ These properties fail to be usable when an Item belongs to multiple Containers at the same time.
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="sioc:shared_by"/> and <resource name="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 <em>creator</em> of the new resource, while linking back to the original.
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="sioc:email_sha1"/> property, whose primary utility (matching things to known contacts) is currently out‐of‐scope for this ontology.
+ </p>
+ </item>
+ <item>
+ <p>
+ The <resource name="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 <ref target="sioc:Site">Site</ref>, but there is no mechanism for actually associating them with the Sites that they are identifiers for (an <ref target="sioc:Item">Item</ref> may belong to multiple Sites).
+ To record an identifier without the presumption of uniqueness, <ptr target="dcterms:identifier"/> is available.
+ If per‐Site uniqueness is needed, qualifying either the belongingness relationship or the identifier itself (perhaps using <ptr target="dc11:identifier"/>) is necessary to indicate the relationship between the identifier and Site.
+ </p>
+ </item>
+ </list>
+ <p>
+ S·I·O·C follows the undesirable pattern of defining many of its properties with a definite domain or range, typically of <ref target="sioc:Item">Item</ref>.
+ 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 <ref target="sioc:addressed_to">addressed to</ref> may be used with things even when they are not a data‐backed Item.
+ </p>
+ <p>
+ Following a similar rationale to the above, this ontology loosens the domains and ranges of many properties from <ptr target="sioc:UserAccount"/> to <ptr target="contact:SocialEntity"/>.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C Access ontology</strong> attempts to model access controls, but is small and feels incomplete in its current form.
+ It does, however, define <ptr target="siocaccess:Status"/> and <ptr target="siocaccess:has_status"/>, which are potentially useful and adopted here.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C Actions ontology</strong> is a bit buggy, but makes an attempt at modelling technological processes thru its <ptr target="siocactions:Action"/> class.
+ This is a weaker form of provenance event information than can be modelled with, for example, <ptr target="(PROV-O)"/>, but it may still be useful, so this ontology defines the terms.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C Argument ontology</strong> 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.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C~Nepomuk ontology</strong> 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).
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C Quotes ontology</strong> 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 <ref target="sioc:Item">Items</ref>, but the combination of a quote and its response (a “block”) is <em>itself</em> 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 <ref target="sioc:Container">Containers</ref> with quote and response Item members (probably undesirable), or as Items whose quote and response are modelled thru some different mechanism.
+ </p>
+ <p>
+ Because of the weaknesses in this model, this ontology refrains from defining the corresponding terms.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C Services ontology</strong> 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.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C~Swan ontology</strong> 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.
+ </p>
+ </item>
+ <item>
+ <p>
+ <strong>The S·I·O·C Types ontology</strong> defines a number of classes for specifying specific types of resources.
+ The <ptr target="sioctypes:Category"/> and <ptr target="sioctypes: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 :—
+ </p>
+ <list>
+ <item>
+ <p>
+ <resource name="sioctypes:ArgumentativeDiscussion"/>, for the same reasons the S·I·O·C Argument ontology is excluded.
+ </p>
+ </item>
+ <item>
+ <p>
+ <resource name="sioctypes:ProjectDirectory"/>, which is defined as a <ref target="sioc:Collection">Collection</ref>, because it is unclear what kinds of <ref target="sioc:Item">Items</ref> it is meant to contain.
+ </p>
+ </item>
+ </list>
+ </item>
+ <item>
+ <p>
+ <strong>The Sioc Wikitalk ontology</strong> 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.
+ </p>
+ </item>
+ </list>
+ </comment>
+ <type>
+ <resource name="dcterms:BibliographicResource"/>
+ </type>
+ <type>
+ <resource name="dcterms:Standard"/>
+ </type>
+ <type>
+ <resource name="foaf:Document"/>
+ </type>
+</NamedIndividual>
Lady’s Gitweb / Vocab / blobdiff