An ontology.
A dictionary of terms.
This ontology provides a formal living reference for the (rather informal) vocabular{y∣ies} used by Lady for her projects. The primary aim of this ontology is to promote consistency; i·e ensure that two projects do not use the same terms in different ways. However, this ontology is some·what opinionated, and there is no guarantee that it will agree with the interpretations of other people.
Many terms defined in this ontology were originally defined else·where. A small number of terms were created by Lady, for which this ontology serves as the authoritative definition. Despite being an “ontology”, the intention of this vocabulary is not to be normatively‐binding but rather to descriptively track usage (as Lady would have it).
Only terms intended for general interchange are recorded here. Some projects may make use of additional terms with implementation‐specific meanings.
| Prefix | Name·space I·R·I |
|---|---|
airports: | http://www.megginson.com/exp/ns/airports# |
anno: | http://www.w3.org/ns/oa# |
awol: | http://bblfish.net/work/atom-owl/2006-06-06/# |
contact: | http://www.w3.org/2000/10/swap/pim/contact# |
dc11: | http://purl.org/dc/elements/1.1/ |
dcmitype: | http://purl.org/dc/dcmitype/ |
dcterms: | http://purl.org/dc/terms/ |
doap: | http://usefulinc.com/ns/doap# |
doc: | http://www.w3.org/2000/10/swap/pim/doc# |
foaf: | http://xmlns.com/foaf/0.1/ |
geo: | http://www.w3.org/2003/01/geo/wgs84_pos# |
ladys: | https://vocab.ladys.computer/terms/ |
owl: | http://www.w3.org/2002/07/owl# |
rdf: | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: | http://www.w3.org/2000/01/rdf-schema# |
rel: | http://www.iana.org/assignments/relation/ |
shacl: | http://www.w3.org/ns/shacl# |
sioc: | http://rdfs.org/sioc/ns# |
siocaccess: | http://rdfs.org/sioc/access# |
siocactions: | http://rdfs.org/sioc/actions# |
sioctypes: | http://rdfs.org/sioc/types# |
skos: | http://www.w3.org/2004/02/skos/core# |
skosxl: | http://www.w3.org/2008/05/skos-xl# |
vocabstatus: | http://www.w3.org/2003/06/sw-vocab-status/ns# |
xsd: | http://www.w3.org/2001/XMLSchema# |
The Atom·Owl Vocabulary, or Awol, was originally an attempt to convert the semantics of The Atom Syndication Format into R·D·F. Consequently, it was one of the first vocabularies to tackle the problem of federated blogging—and what we would today call federated social media. The specification is full of holes and questions, but never·the·less some aspects of how it handles things are far superior to later, more protocol‐driven federated media approaches.
This ontology defines all of Awol, except for :—
awol:XML, which does not appear in the original Awol documentation and seems to have been quietly added in the six months after publication. This class is of limited utility, as it is not a type of Plain Text Content.
The type‐specific properties awol:text, awol:xhtml, awol:html, and awol:xml. body can easily accommodate all of these use·cases, altho note that this ontology sets particular restrictions on it, depending on the media type of the containing Content.
awol:uri, as its intended meaning is conveyed using ordinary R·D·F named nodes. To indicate the preferred I·R·I for a thing, use preferred I·R·I.
Awol supplies restrictions on the domains and ranges of many properties, and describes many of them as functional, limiting their utility outside of its own data model. This ontology maintains the restrictions on the ranges, which can be significant, but loosens the restrictions on the domains and cardinality.
The Dublin Core Metadata Initiative (D·C·M·I) metadata terms (i·e, the Dublin Core vocabulary) are some of the earliest attempts at standardizing metadata encoding on the Web. Because of their age and association with library science (the “Dublin” is Dublin, Ohio, the headquarters of O·C·L·C), these terms are widely used and referenced both in metadata resources themselves and in other specifications which describe them. Not every aspect of the model has stood the test of time, but core terms like title are indispensible.
D·C·M·I defines four different name·spaces. Of these, dcterms: and dcmitype: are the straightforwardly useful as documented. The dcam: name·space is not really useful at all, as much more sophisticated solutions to its problem space exist.
The dc11: name·space requires more careful consideration. Each term in the dc11: name·space is duplicated in the dcterms: name·space, and in general the latter is recommended. However, the dcterms: name·space is not use·able in all cases, especially within an Owl ontology. For example, dcterms:language is defined with a range of dcterms:LinguisticSystem. One might consider dcterms:LinguisticSystem to be an Owl Class of objects, and consequently dcterms:language to be an object property.1 This interpretation means dcterms:language cannot be used as a data property or take data values, such as xsd:languages. Yet dc11:language, which has no defined range in D·C·M·I, can be defined as a data property instead,2 and accept the values that dcterms:language cannot.
The actual definitions of the D·C·M·I terms do not have an unambiguous mapping into Owl, but this ontology is forced to take a stance as to what such a mapping would be. It tries to do so in the most broadly‐compatible, uncontroversial way for those terms in the dcterms: name·space. It then takes the opposite position for terms in dc11:, with the assumption that data which is not using the dcterms: name·space is refusing to do so with good reason. Neither of these positions are incontrovertible, and not all R·D·F graphs will conform to them. But this is the best that can be done for a set of name·spaces which are foundational to so many internet standards and yet themselves so loosely‐specified.
Because of their ubiquity, all terms from dc11:, dcterms:, and dcmitype: are given definitions in this ontology, regardless of perceived utility, with the following exceptions :—
dcterms:AgentClass, and the properties which have it as their range (dcterms:audience, dcterms:educationLevel, dcterms:mediator). The use of dcterms:AgentClass as both a class (of which Agents are instances) and an object isn¦t problematic ⅌·se, but this kind of metamodelling is not really bestpractices anymore. It is better to model kinds of agents as a role which agents (or qualified agents) possess rather than a type which they have; in general, typing information is not useful for grabbag qualifications on objects, but rather as a mechanism for qualifying or contextualizing the properties which an object has.
Vocabulary encoding schemes, as they depend on dcam: and Skos is a better solution.
Syntax encoding schemes, i·e datatypes. The use of datatypes beyond the core X·S·D and R·D·F set on literals for indicating the format of the literal data is an idea from early in R·D·F development which hasn¦t withstood the test of time: Such datatypes can¦t typically be reasoned about, or constrained, and offer little over plain string typing in a qualified relation that also indicates the type of data.
Description Of A Project (D·O·A·P) is an early vocabulary aimed at describing software projects, and in particular open‐source ones. In the software distribution world, it has been largely supplanted by S·P·D·X, but S·P·D·X is undesirable for more general metadata purposes for a number of reasons.1 Consequently, D·O·A·P still gets a fair bit of use today.
This ontology aims to support the core functionality of D·O·A·P, but it ignores some aspects of the model, including :—
The subclasses of Repository: doap:ArchRepository, doap:BazaarBranch, doap:BKRepository, doap:CVSRepository, doap:DarcsRepository, doap:GitBranch, doap:GitRepository, doap:HgRepository, and doap:SVNRepository. Using in format to indicate the format of the repository instead is recommended, in situations where this information is relevant.
The properties doap:anon-root and doap:module, which are only useful for certain kinds of Repository.
This specification describes the pagination and archiving of Atom feeds, and consequently is a kind of extension to The Atom Syndication Format. As with that specification, it provides the normative definition for a few Relation Types. Note that rel:previous and rel:next were previously defined in H·T·M·L, but H·T·M·L¦s approach to linking is generally unsuitable for use with R·D·F and not considered normative by this ontology.
F·O·A·F is an early and widely‐used vocabulary which grew some·what organically within the R·D·F·Web community. It is not necessarily weldesigned in all respects, but it has been commonly deployed as a vocabulary for modelling Agents, and is often used alongside D·C·M·I Metadata Terms (which models the things they make). D·C·M·I and F·O·A·F have a good neighbour agreement formalizing the fact that the two vocabularies often go hand‐in‐hand.
Due to its organically‐developed nature, terms in F·O·A·F were given a status, meant to indicate how stable their definitions ought to be considered. These statuses have not been updated in over a decade, and are not preserved here; however, a status of at least "testing" was deemed a criterion for inclusion.
Otherwise, this ontology provides definitions for the bulk of F·O·A·F, wilfully excluding the following properties :—
foaf:interest, foaf:schoolHomepage, and foaf:workplaceHomepage are roundabout terms which indicate Documents which have a primary topic of a thing, rather than just indicating the thing itself. This was a pragmatic choice by the authors of F·O·A·F because it was assumed these documents would have more welknown, and thus easily-queryable, I·R·I¦s. But R·D·F tooling and understanding has significantly matured in the years since these properties were introduced, and they are far from bestpractice now. (Just make a bloody blank node!)
Likewise, foaf:weblog indicates a Document, not a Weblog.
foaf:mbox and foaf:mbox_sha1sum are properties for identifying the original, not current, owner of an internet mailbox, and thus not useful for the actual sending of messages. Originally, these properties were conceived as a means of determining Agent identity; in the case of foaf:mbox, this intent is much better served by just using a tag: U·R·I, which can be email‐derived. foaf:mbox_sha1sum is of questionable utility in practice.
foaf:PersonalProfileDocument is a subclass of Document which is used for R·D·F documents whose primary topic is their maker. But this relationship is more useful stated explicitly (i·e, with properties), and the class offers little.
A number of properties (foaf:aimChatID, foaf:icqChatID, foaf:jabberID, foaf:msnChatID, foaf:skypeID, foaf:yahooChatID) are tied to specific online platforms; these are better served by the generic properties surrounding Online Accounts.
foaf:myersBriggs, for lack of any strong argument for inclusion.
F·O·A·F also makes use of a single class in the geo: name·space, Spatial Thing. This ontology like·wise adopts this term.
This specification defines the conceptual structure for Owl, independent of any serialization format. Many terms in the Owl name·space are actually “defined” by Owl 2 Mapping To R·D·F Graphs, which explains how to convert this conceptual structure into R·D·F graphs. However, this specification provides the definition for the few terms which are actually relevant to this ontology from a nonmeta perspective; namely its set of annotation properties. It also redefines a few terms from R·D·F Schema 1.1 for use in annotations.
R·D·F Schema introduces itself as providing “a data‐modelling vocabulary for R·D·F data”. This is correct, but it is important to understand that it performs this function in two different ways :—
It provides properties for modelling R·D·F vocabularies in terms of classes, properties, literals, and the relationships between them.
It provides data structures which are useful for representing data in R·D·F, and a few additional utility properties for expressing common concepts.
The terms in the first category are effectively subsumed within Owl 2 Mapping To R·D·F Graphs, and are not defined here (they are axiomatic). The terms in the second category, on the other hand, are all given definitions in this ontology as they are broadly useful. In addition to being defined within the core rdfs: name·space, R·D·F Schema also provides the formal definition for many terms in the rdf: one.
The Shapes Constraint Language, or Shacl, provides a vocabulary for defining constraints on R·D·F graphs. In this sense, it is very useful as a base model for describing how vocabularies should be used, but not very useful for modelling concepts within the vocabularies themselves. Consequently, most terms from Shacl are not defined here. However, this ontology does annotate itself with declares, to declare which prefixes it recommends and uses for various name·spaces.
The Simple Knowledge Organization System, or Skos, provides a core vocabulary for defining and organizing pieces of knowledge, known as Concepts. The model is generic enough to be usable for everything from metadata tags to thesauruses, and is particularly useful as the basis for more specialized knowledge models.
Skos expresses constraints (i·e, integrety conditions) on some of its terms which are not formally expressible in Owl. Some constraints, like those involving transitive properties, are expressible but not reasonable, and so are left out of this ontology. Constraints are only minimally useful in an ontological sense anyway, as reasoning systems make for poor validators.
Skos formally defines its simple labels as annotation properties, meaning they cannot be reasoned about. Skos·X·L (defined in an appendix to the Skos specification) instead defines labels using objects, enabling reasoning.1 Skos·X·L labels are generally recommended anyway, as the ability to attach additional properties to them is often useful.
This ontology includes all of Skos, as it is incredibly useful baseline model for knowledge organization and representation.
Swap (the Semantic Web Application Platform) was a very early set of tools for working with linked data, created by timbl. It came packaged with a number of early, experimental, and frankly demo vocabularies, provided as Notation·3 files in the pim/ directory (your guess is as good as mine).
For the most part, the problems that these vocabularies were trying to solve have now been better solved else·where. Never·the·less, some terms are still useful, or at least generally compatible with those from later vocabularies. Those terms are defined here.
The vocabularies encompassed by Swap P·I·M include :—
Contact: This vocabulary is, by far, the most widely‐used, and most likely to be useful, vocabulary in this set: F·O·A·F specifically calls out nearest airport as an alternative to based near. Most of its terms are included in this ontology, but a few are not :—
contact:title and contact:departmentName should be properties of roles, not people; as it stands, they become unusable if a person is ever involved in more than one organization at the same time.
contact:emailAddress, contact:mailboxURI, and contact:homePageAddress are explicitly discouraged in their original definitions.
contact:Male and contact:Female, as classes, are undocumented and likely misguided.
Doc: This vocabulary revolves around properties for describing Works, which are defined essentially as pieces of intellectual property. This is a problematic definition which limits the utility of the rest of the vocabulary. This ontology defines only the problematic Work class itself, as well as the version property (but only one of the two very different definitions provided), which is not Work‐specific.
I·Calendar: This is a small and experimental attempt at encoding calendaring information into R·D·F. W·3·C later created R·D·F Calendar, which is a much more fully‐fleshed‐out solution and should be used instead. Both are considered out‐of‐scope for this ontology.
Mortgage: This is a vocabulary aimed at representing the information in a “e·g Bank of America online mortgage statement” in R·D·F. It is probably not sufficient to the task and regardless is out‐of‐scope for this ontology, which does not care about finances.
Qif: This is a vocabulary targeted at representing information for personal finances. It is very unclear why some·one would ever want to make their personal finances a part of the Semantic Web, so this vocabulary has been deemed out‐of‐scope for this ontology.
Track: This is a very simple vocabulary for issue tracking. It suffers from a number of flaws :—
The properties for title and summary have their domain restricted to issues, which is needlessly restrictive.
track:documentConcerned is a bad name; issues may be filed against things which are not conventionally thought of as “documents”. The actual range of this property is Work.
Issue lifecycle is determined via a number of properties which point at Works that denote the change. Correct interpretation requires that these Works be given sequential publication dates (or be sequenced thru some other mechanism). A better model would be to have a single property which associates the issue with a dated Specific Resource, whose purpose provides the effect of the change. Or, to link issues to dated events, rather than of Works.
Considering basically every aspect of this vocabulary has flaws, there¦s really no good argument for including it. Evo·Ont provides a much better model for issue tracking, building on W·3·C¦s.
Travel Terms: This vocabulary defines terms for modelling air travel via commercial airlines. There¦s not anything obviously wrong with it, but it¦s out‐of‐scope for this ontology.
U·S·P·S: This vocabulary aims to define terms for representing in R·D·F the specific fields used by the United States Postal Service, with the goal of modelling the specific mailing locations used by specific pieces of physical mail. This ontology does not attempt to model specific pieces of physical mail, so this vocabulary is out of scope. For describing the locations and addresses of people, to the extent that is needed, better vocabularies exist.
Two terms in the airports: name·space, I·A·T·A station code and I·C·A·O airport code, are also defined, for use with nearest airport. In cases where a property in Swap P·I·M is defined as equivalent to another property in a different name·space, it is strongly recommended that you use the other property instead.
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.
This “(editors draft of a potential) W·3·C Interest Group Note” defines only a single annotation property, has status. It was created for use with F·O·A·F to annotate classes and properties as they evolved and give some hint as to the maturity of their usage.
This ontology defines has status, but only uses it with terms in the ladys: name·space. Inclusion of terms from other name·spaces into this ontology implies at least a nominal level of stability.
Most Atom‐related properties are actually defined by Awol, but the Atom Syndication Format itself provides the normative definitions for the initial set of Relation Types.
The Web Annotation Vocabulary provides the terms and definitions which underpin the related Web Annotation Data Model. The terminology (and specifications) can make the underlying concepts seem a bit obtuse, but fundamentally a Web Annotation is a (typically purposeful) object which has a target and associates it with zero or more bodies. If you can get past all the language, this is fundamentally a very simple model which is broadly applicable.
This ontology does not define every term in the Web Annotation Vocabulary, but it does define most of them. Terms it excludes include :—
anno:annotationService, as it merely offers a discovery endpoint for the Web Annotation Protocol, which this ontology makes no claims to support.
anno:Choice, as it defines what is in essence a rendering detail. If two bodies are, for example, equivalent but in different languages, it would be better to provide that information via relationships between the bodies themselves, and leave it to renderers to determine whether to display both or choose between them.
anno:Style, anno:CssStyle, anno:styledBy, and anno:styleClass, as these are rendering details which ought to be left to applications.
anno:SvgSelector is underspecified, and its value is generally described as a string, not the more appropriate rdf:XMLLiteral.
anno:TextualBody follows an undesirable pattern of recommending a plaintext string value, with its language and media type specified thru other properties. For plaintext strings, it is better for language to be provided via the rdf:langString mechanism, and it is better that X·M·L values be provided as rdf:XMLLiterals. Because these things complicate the processing model and it is unlikely that existing Web Annotation tools would support them, this ontology chose not to complicate anno:TextualBody. Instead, Content should be used.
anno:bodyValue, for the same reasons as anno:TextualBody.
anno:cachedSource is semantically muddled; Time States don¦t generally have sources, so how can they have cached ones? This would have been better modelled as a property of the enclosing Resource Selection.
anno:renderedVia, while providing interesting and potentially meaningful provenance information, adds additional complexity to the model without any known practical use·cases. This ontology may choose to define it at a later time if practical use·cases are found.
Properties originally defined by other vocabularies, when those vocabularies are not otherwise defined in this ontology.