X-Git-Url: https://git.ladys.computer/Vocab/blobdiff_plain/2304b7c34ca0e67a39896e474f5add121f0bdfed..2f9af9a7ee7f501ca6bc102f0f0a6f689f391b51:/data/named_individuals/_SIOC_ diff --git a/data/named_individuals/_SIOC_ b/data/named_individuals/_SIOC_ new file mode 100644 index 0000000..a8c32b2 --- /dev/null +++ b/data/named_individuals/_SIOC_ @@ -0,0 +1,169 @@ + + + + + + +

+ Building on the work of and , 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 class (use instead). +

+ + +

+ The class, and related properties , , , and . + 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 property, which is needlessly formal. +

+ + +

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

+ + +

+ The and 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 and 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 property, whose primary utility (matching things to known contacts) is currently out‐of‐scope for this ontology. +

+ + +

+ The 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, is available. + If per‐Site uniqueness is needed, qualifying either the belongingness relationship or the identifier itself (perhaps using ) 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 to . +

+ + +

+ 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 and , 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 class. + This is a weaker form of provenance event information than can be modelled with, for example, , 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 and 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 :⁠— +

+ + +

+ , for the same reasons the S·I·O·C Argument ontology is excluded. +

+ + +

+ , 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. +

+ + + + + + + + + + + + +