Lady’s Gitweb - Vocab/blob - data/named_individuals/_SIOC_

   1 <?xml version="1.0"?>
   2 <!--
   3 SPDX-FileCopyrightText: 2025 Lady <https://www.ladys.computer/about/#lady>
   4 SPDX-License-Identifier: CC0-1.0
   5 -->
   6 <!DOCTYPE NamedIndividual SYSTEM "../../DTD">
   7 <NamedIndividual name="http://rdfs.org/sioc/spec/">
   8         <label xml:lang="en">S·I·O·C</label>
   9         <comment xml:lang="en">
  10                 <p>
  11                         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.
  12                         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.
  13                 </p>
  14                 <p>
  15                         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.
  16                         The list of modules is as follows :⁠—
  17                 </p>
  18                 <list>
  19                         <item>
  20                                 <p>
  21                                         <strong>The S·I·O·C Core ontology</strong> defines all of the core terms of the S·I·O·C model.
  22                                         This ontology includes all of S·I·O·C Core, except for :⁠—
  23                                 </p>
  24                                 <list>
  25                                         <item>
  26                                                 <p>
  27                                                         The deprecated <resource name="sioc:User"/> class (use <ptr target="sioc:UserAccount"/> instead).
  28                                                 </p>
  29                                         </item>
  30                                         <item>
  31                                                 <p>
  32                                                         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"/>.
  33                                                         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.
  34                                                         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.
  35                                                         This would enable the roles themselves to be modelled in a context‐independent manner.
  36                                                 </p>
  37                                         </item>
  38                                         <item>
  39                                                 <p>
  40                                                         The <resource name="sioc:embeds_knowledge"/> property, which is needlessly formal.
  41                                                 </p>
  42                                         </item>
  43                                         <item>
  44                                                 <p>
  45                                                         The <resource name="sioc:link"/> property, which has unclear utility.
  46                                                         Consider <ptr target="awol:link"/> instead, or just use ordinary R·D·F named node functionality.
  47                                                 </p>
  48                                         </item>
  49                                         <item>
  50                                                 <p>
  51                                                         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>.
  52                                                         These properties fail to be usable when an Item belongs to multiple Containers at the same time.
  53                                                 </p>
  54                                         </item>
  55                                         <item>
  56                                                 <p>
  57                                                         The <resource name="sioc:shared_by"/> and <resource name="sioc:sibling"/> properties, which are underspecified and probably an inadequate model.
  58                                                         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.
  59                                                 </p>
  60                                         </item>
  61                                         <item>
  62                                                 <p>
  63                                                         The <resource name="sioc:email_sha1"/> property, whose primary utility (matching things to known contacts) is currently out‐of‐scope for this ontology.
  64                                                 </p>
  65                                         </item>
  66                                         <item>
  67                                                 <p>
  68                                                         The <resource name="sioc:id"/> property, because S·I·O·C makes restrictions which are difficult to practically assess.
  69                                                         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).
  70                                                         To record an identifier without the presumption of uniqueness, <ptr target="dcterms:identifier"/> is available.
  71                                                         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.
  72                                                 </p>
  73                                         </item>
  74                                 </list>
  75                                 <p>
  76                                         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>.
  77                                         This pattern exists for human benefit:
  78                                         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.
  79                                         However, from a modelling standpoint, it severely restricts the utility of the properties.
  80                                         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.
  81                                 </p>
  82                                 <p>
  83                                         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"/>.
  84                                 </p>
  85                         </item>
  86                         <item>
  87                                 <p>
  88                                         <strong>The S·I·O·C Access ontology</strong> attempts to model access controls, but is small and feels incomplete in its current form.
  89                                         It does, however, define <ptr target="siocaccess:Status"/> and <ptr target="siocaccess:has_status"/>, which are potentially useful and adopted here.
  90                                 </p>
  91                         </item>
  92                         <item>
  93                                 <p>
  94                                         <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.
  95                                         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.
  96                                 </p>
  97                         </item>
  98                         <item>
  99                                 <p>
 100                                         <strong>The S·I·O·C Argument ontology</strong> attempts to model “issue‐based information systems”.
 101                                         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.
 102                                 </p>
 103                         </item>
 104                         <item>
 105                                 <p>
 106                                         <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.
 107                                         This ontology will define its own mappings, should they be necessary (at present, Nepomuk is out‐of‐scope).
 108                                 </p>
 109                         </item>
 110                         <item>
 111                                 <p>
 112                                         <strong>The S·I·O·C Quotes ontology</strong> defines a mechanism for modelling quotes alongside their responses.
 113                                         Altho this idea has potential, the modelling decisions are a bit confusing:
 114                                         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?
 115                                         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.
 116                                 </p>
 117                                 <p>
 118                                         Because of the weaknesses in this model, this ontology refrains from defining the corresponding terms.
 119                                 </p>
 120                         </item>
 121                         <item>
 122                                 <p>
 123                                         <strong>The S·I·O·C Services ontology</strong> provides terms for modelling Web services and their endpoints.
 124                                         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.
 125                                 </p>
 126                         </item>
 127                         <item>
 128                                 <p>
 129                                         <strong>The S·I·O·C~Swan ontology</strong> defines mappings to the Semantic Web Applications in Neuromedicine vocabulary (Swan).
 130                                         It provides one additional term for online journals, which this ontology does not adopt.
 131                                 </p>
 132                         </item>
 133                         <item>
 134                                 <p>
 135                                         <strong>The S·I·O·C Types ontology</strong> defines a number of classes for specifying specific types of resources.
 136                                         The <ptr target="sioctypes:Category"/> and <ptr target="sioctypes:Tag"/> classes are broadly‐applicable and defined here.
 137                                         The remaining types are of more dubious utility, but are generally harmless and have been defined for completeness, with the following exceptions :⁠—
 138                                 </p>
 139                                 <list>
 140                                         <item>
 141                                                 <p>
 142                                                         <resource name="sioctypes:ArgumentativeDiscussion"/>, for the same reasons the S·I·O·C Argument ontology is excluded.
 143                                                 </p>
 144                                         </item>
 145                                         <item>
 146                                                 <p>
 147                                                         <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.
 148                                                 </p>
 149                                         </item>
 150                                 </list>
 151                         </item>
 152                         <item>
 153                                 <p>
 154                                         <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.
 155                                         This ontology has no investment in this model and considers modelling it to be out of scope.
 156                                 </p>
 157                         </item>
 158                 </list>
 159         </comment>
 160         <type>
 161                 <resource name="dcterms:BibliographicResource"/>
 162         </type>
 163         <type>
 164                 <resource name="doap:Specification"/>
 165         </type>
 166 </NamedIndividual>