Extended Activity Streams 2.0 Vocabulary
The Bibliographic Ontology describes bibliographic things on the semantic Web in RDF. This ontology can be used as a citation ontology, as a document classification ontology, or simply as a way to describe any kind of document in RDF. It has been inspired by many existing document description metadata formats, and can be used as a common ground for converting other bibliographic data sources.
Ontology for Certificates and crypto stuff. This is in development. Some other ontologies to look at: * http://www.w3.org/2000/10/swap/crypto + has cwm builtins: http://www.w3.org/2000/10/swap/doc/Trust - a bit old perhaps. It imports daml+oil - would help to be more completely specified - uses literals as subjects a little liberally, which makes this a bit difficult to work with frameworks that don't permit this * http://xmlns.com/wot/0.1/ - limited very much to PGP (though on can map PGP to X509) - a little coarse grained, mixes up the PGP certificate with the PGP public key * Todo: - add some classes and relations for DSA - should this all be in one file? Or should this be cut up a little? Say one file for the general CERT ontology, and then files for RSA, DSA, PGP, etc... Or perhaps it does not really matter? - expand more on the certification side of things - verify this by security experts - owl2 has some constructs for combined inverse functional properties. This may be useful to use in defining an RSA key which is identified by two numbers. - also create html version of the spec by using this as a template. - should comments such as this be in html?
Ontology for Certificates and crypto stuff.
Representing Content in RDF as defined by http://www.w3.org/TR/Content-in-RDF/
This document describes the RDFS vocabulary description used in the Metadata Vocabulary for Tabular Data tabular-metadata along with the default JSON-LD Context.
Common Tag RDF vocabulary, described using W3C RDF Schema. Common Tags allows documents and document fragments (any resource which can be identified by a URI) to be labeled with keywords and URIs, unambigiously idenfying the concepts covered by the resource.
Defines SHACL functions (with URIs) representing the built-in SPARQL 1.1 functions and operators such as isIRI and / (divide). Each of these is represented by an instance of sh:Function with a URI such as sparql:divide. The declared parameters indicate the number of arguments but no other constraints have been added.
DASH is a SHACL library for frequently needed features and design patterns. The constraint components in this library are 100% standards compliant and will work on any engine that fully supports SHACL.
The DBpedia ontology provides the classes and properties used in the DBpedia data set.
Dublin Core Metadata Element Set, Version 1.1
Metadata terms for vocabulary description
DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. By using DCAT to describe datasets in data catalogs, publishers increase discoverability and enable applications easily to consume metadata from multiple catalogs. It further enables decentralized publishing of catalogs and facilitates federated dataset search across sites. Aggregated DCAT metadata can serve as a manifest file to facilitate digital preservation. DCAT is defined at http://www.w3.org/TR/vocab-dcat/. Any variance between that normative document and this schema is an error in this schema.
The Description of a Project (DOAP) vocabulary, described using W3C RDF Schema and the Web Ontology Language.
Description of a Project (DOAP) vocabulary
DPROD extends DCAT to enable publishers to describe Data Products and data services in a decentralized way.
The Data Quality Vocabulary (DQV) is seen as an extension to DCAT to cover the quality of the data, how frequently is it updated, whether it accepts user corrections, persistence commitments etc. When used by publishers, this vocabulary will foster trust in the data amongst developers.
The Dataset Usage Vocabulary (DUV) is used to describe consumer experiences, citations, and feedback about datasets from the human perspective.
Formal schema of the Evaluation and Report Language (EARL) 1.0
Evaluation and Report Language (EARL) 1.0 Schema
Guidelines: for the purpose of flexibility and interoperability with a wider range of implementations, some properties purposefully do not have a range and accept either a resource or a literal. When a resource is used, it is recommended to reuse objects defined in the model (e.g. pair hasEvent/Event or hasRole/Role). Example 1: x hasRole 'actor'. Example 2: x hasRole _:Role_1 (a reference to the Concept identifier from a SKOS Role vocabulary defined in the ontology).
Vocabulary to describe an Exif format picture data. All Exif 2.2 tags are defined as RDF properties, as well as several terms to help this schema.
The Friend of a Friend (FOAF) RDF vocabulary, described using W3C RDF Schema and the Web Ontology Language.
An RDF/OWL vocabulary for representing spatial information
The Geonames ontologies provides elements of description for geographical features, in particular those defined in the geonames.org data base
The GoodRelations ontology provides the vocabulary for annotating e-commerce offerings (1) to sell, lease, repair, dispose, or maintain commodity products and (2) to provide commodity services. GoodRelations allows describing the relationship between (1) Web resources, (2) offerings made by those Web resources, (3) legal entities, (4) prices, (5) terms and conditions, and the aforementioned ontologies for products and services (6). For more information, see http://purl.org/goodrelations/ Note: The base URI of GoodRelations is http://purl.org/goodrelations/v1. Please make sure you are only using element identifiers in this namespace, e.g. http://purl.org/goodrelations/v1#BusinessEntity. There may be copies of the ontology file on the Web which can be retrieved from other locations, BUT THOSE LOCATIONS MUST NOT BE USED AS THE BASIS OF IDENTIFIERS. If you use GoodRelations for scientific purposes, please cite our paper: Hepp, Martin: GoodRelations: An Ontology for Describing Products and Services Offers on the Web, Proceedings of the 16th International Conference on Knowledge Engineering and Knowledge Management (EKAW2008), September 29 - October 3, 2008, Acitrezza, Italy, Springer LNCS, Vol. 5268, pp. 332-347. PDF at http://www.heppnetz.de/publications/
The GoodRelations Vocabulary for Semantic Web-based E-Commerce
This ontology is a translation of the General Transit Feed Specification towards URIs. Its intended use is creating an exchange platform where the Linked GTFS model can be used as a start to get the right data into the right format. For semantics of the classes and properties, see https://developers.google.com/transit/gtfs/reference.
A namespace for describing HTTP messages (http://www.w3.org/Protocols/rfc2616/rfc2616.html)
The Hydra Core Vocabulary is a lightweight vocabulary to create hypermedia-driven Web APIs. By specifying a number of concepts commonly used in Web APIs it enables the creation of generic API clients.
Vocabulary URIs defined in the Linked Data Platform (LDP) namespace.
The W3C Linked Data Platform (LDP) Vocabulary
This is a new version of the final draft published by the European Commission in May 2012, revised according to the results of the ISA Core Location Pilot (see Section Change History for the list of changes). It is currently under the control of the Locations and Addresses Community Group, but is not under active development or review. Comments and queries should be sent to that group via public-locadd@w3.org. Terms defined here may be deprecated by that or future groups but will not disappear or their definition change.
Metadata4Ing defines classes and properties or reuses such classes and properties from other ontologies to describe research processes and research data management in NFDI4Ing. New concepts and properties are located in the namespace of Metadata4Ing. Metadata4Ing does not import complete ontologies for the sake of relevance, readability, understandability and usability by and for engineers. Instead, it tries to make re-use of existing identifiers for classes and properties by re-using all or a relevant subset of the axioms from the original ontology. These statements have been extracted in different ways, e.g. by using Protégé tools importing an ontology and copying axioms of relevant items to Metadata4Ing or by download from data services or raw files of ontologies and manual copypasting. In some cases there was a need to extend or modify the original set of statements about an entity, e.g. because labels and definitions were expressed with a different owl:AnnotationProperty than the rest of Metadata4Ing, or because a skos:preflabel or a skos:definition in any of the languages we would like to support was missing. Any editorial changes on elements from external ontologies are declared in Metadata4Ing by an annotation with skos:editorialNote at item-level. To get the original set of statements we encourage to visit the original namespace of the respective item. Metadata4Ing reuses elements from the following ontologies: - BIBO = Bibliographic Ontology - BIRO = Bibliographic Reference Ontology - CR = Croissant - DCAT = Data Catalog - DCC = Digital Calibration Certificate - DCTERMS = Dublin Core Terms - EMMO = European Materials and Modelling Ontology - FOAF = Friend of a Friend - OBO = Open Biological and Biomedical Ontologies: - BFO = Basic Formal Ontology - RO = Relation Ontology - OWL = Web Ontology Language - PIMS-II = PIMS Interoperability Infrastructure - PROV = Provenance Namespace - QUDT = Quantities, Units, Dimensions and Types - RDF = Resource Description Framework - RDFS = RDF Schema - SCHEMA = schema.org - D-SI = Digital System of Units - SIO = Semanticscience Integrated Ontology - SKOS = Simple Knowledge Organization System - SSN = Semantic Sensor Network Ontology - VANN = Vocabulary for Annotating vocabulary descriptions - XSD = XML Schema Definition
Metadata4Ing: An ontology for describing the generation of research data within a scientific activity.
Created by Tobias Buerger, Jean Pierre Evain and Pierre-Antoine Champin with the RDFS Taskforce within the W3C Media Annotation Working Group.
This document describes the MADS/RDF (Metadata Authority Description Schema in RDF) vocabulary, a data model for authority and vocabulary data used within the library and information science (LIS) community, which is inclusive of museums, archives, and other cultural institutions. It is presented as an OWL ontology. MADS/RDF is a knowledge organization system (KOS) designed for use with controlled values for names (personal, corporate, geographic, etc.), thesauri, taxonomies, subject heading systems, and other controlled value lists. It is closely related to SKOS, the Simple Knowledge Organization System and a widely supported and adopted RDF vocabulary. Given the close relationship between the aim of MADS/RDF and the aim of SKOS, the MADS ontology has been fully mapped to SKOS. Unlike SKOS, however, which is very broad in its application, MADS/RDF is designed specifically to support authority data as used by and needed in the LIS community and its technology systems. For example, MADS/RDF provides a means to record data from the Machine Readable Cataloging (MARC) Authorities format in RDF for use in semantic applications and Linked Data projects. MADS/RDF is designed to support the description of cultural and bibliographic resources. Data described using MADS/RDF, therefore, assists with identifying and annotating bibliographic and cultural resources. MADS/RDF is not focused on the description of Real World Objects. Although a MADS/RDF description may contain information specific to the Real World Object associated with the MADS/RDF authoritative label, the MADS/RDF ontology distinguishes between these two entities – the RWO and the Authority. Updated: 29 October 2015. Addition of new properties, madsrdf:activityEndDate, madsrdf:activityStartDate, madsrdf:associatedLanguage, madsrdf:associatedLocale, madsrdf:birthDate, madsrdf:birthPlace, madsrdf:deathDate, madsrdf:deathPlace, madsrdf:entityDescriptor, madsrdf:establishDate, madsrdf:fieldOfActivity, madsrdf:gender, madsrdf:hasAffiliation, madsrdf:honoraryTitle, madsrdf:isIdentifiedByAuthority, madsrdf:occupation, madsrdf:prominentFamilyMember, madsrdf:terminateDate, madsrdf:fullerName, madsrdf:creationDateStart, madsrdf:creationDateEnd, madsrdf:workOrigin, madsrdf:hasChararacteristic. The MADS/RDF to SKOS/RDF mapping was done by Antoine Isaac. The MADS/RDF model and ontology benefited significantly as a result of the fruitful discussions surrounding his effort to map the MADS/RDF ontology to SKOS.
MADS/RDF (Metadata Authority Description Schema in RDF)
The Web Annotation ontology defines the terms of the Web Annotation vocabulary. Any changes to this document MUST be from a Working Group in the W3C that has established expertise in the area.
The OpenID Connect vocabulary used by the Solid-OIDC authentication specification.
Vocabulary for describing organizational structures, specializable to a broad variety of types of organization.
This ontology partially describes the built-in classes and properties that together form the basis of the RDF/XML syntax of OWL 2. The content of this ontology is based on Tables 6.1 and 6.2 in Section 6.4 of the OWL 2 RDF-Based Semantics specification, available at http://www.w3.org/TR/owl2-rdf-based-semantics/. Please note that those tables do not include the different annotations (labels, comments and rdfs:isDefinedBy links) used in this file. Also note that the descriptions provided in this ontology do not provide a complete and correct formal description of either the syntax or the semantics of the introduced terms (please see the OWL 2 recommendations for the complete and normative specifications). Furthermore, the information provided by this ontology may be misleading if not used with care. This ontology SHOULD NOT be imported into OWL ontologies. Importing this file into an OWL 2 DL ontology will cause it to become an OWL 2 Full ontology and may have other, unexpected, consequences.
This document is published by the Provenance Working Group (http://www.w3.org/2011/prov/wiki/Main_Page). If you wish to make comments regarding this document, please send them to public-prov-comments@w3.org (subscribe public-prov-comments-request@w3.org, archives http://lists.w3.org/ Archives/Public/public-prov-comments/). All feedback is welcome.
This vocabulary allows multi-dimensional data, such as statistics, to be published in RDF. It is based on the core information model from SDMX (and thus also DDI).
Vocabulary for multi-dimensional (e.g. statistical) data publishing
This is the RDF Schema for the RDF vocabulary terms in the RDF Namespace, defined in RDF 1.1 Concepts.
This document describes the RDFa Vocabulary for Term and Prefix Assignment. The Vocabulary is used to modify RDFa 1.1 processing behavior.
RDFa Vocabulary for Term and Prefix Assignment, and for Processor Graph Reporting
Vocabulary for expressing reviews and ratings using the Resource Description Framework. It is compatible with hReview and conforms to OWL Lite
Introduction RiC-O (Records in Contexts-Ontology) is an OWL ontology for describing archival record resources. As the third part of Records in Contexts standard, it is a formal representation of Records in Contexts Conceptual Model (RiC-CM). This version, which is v1.0.2, is the latest official release. It is compliant with RiC-CM v1.0. The following diagram shows the main RiC-CM 1.0 entities and a few relations between them: RiC-O design principles The following design principles were followed when developing RiC-O. 1. RiC-O is a domain and reference ontology. RiC-O provides a generic vocabulary and formal rules for creating RDF datasets (or generating them from existing archival metadata) that describe in a consistent way any kind of archival record resource. It supports publishing RDF datasets as Linked Data, querying them using SPARQL, and making inferences using the logic of the ontology. While some projects have built some specific ontologies for describing archives, in 2013 no generic domain ontology existed for the specific needs of the archival community. This is why EGAD decided to develop RiC-O as a part of RiC standard. Apart from this first, main target, RiC-O, as a technical implementation of RiC-CM that also extends and refines it and that includes formal logic, can guide or inspire, in many ways, the development of any tool or system that manages (i.e. stores, enables to edit or processes) and publishes descriptive archival metadata.. Of course, other technical implementations of RiC-CM may be developed later on. Also, the current technical implementations of the former ICA standards, e.g. EAD and EAC-CPF XML schemas, should be made closer to RiC-CM in the future; on this topic, see the news and announcements of the Technical Subcommittee on Encoded Archival Standards (TS-EAS) of the Society of American Archivists. As RiC-O is a generic, domain ontology, it does not address by itself every specific need or expectation that may occur in every archival institution or project. It is rather a high level framework and an institution or project implementing RiC-O can apply only such a subset of properties as meets their needs, or extend the specification according to their particular requirements, or do both. As a domain ontology, RiC-O, at this stage, does not borrow from other existing ontologies (such as the cultural heritage models – IFLA-LRM and CIDOC-CRM, PREMIS, or PROV-O). It should therefore be easier, for an archival institution or archival project, to understand, implement and maintain RiC-O within its system. Alignment with those and other models, where possible, will be undertaken in a future revision cycle to support the interconnected nature of resource description across the domains. This is of course essential for interconnecting RDF datasets conforming to RiC-O with other datasets, or for using parts of RiC-O in other contexts than the archival or records management realm. 2. RiC-O is immediately usable. This is a key feature. Metadata conforming to superseded ICA standards can be transformed to RiC-O successfully. Converting existing archival metadata created or generated in current information systems and compliant with ICA standards to RDF/RiC-O is possible without losing data or structure. During the ongoing development process of RiC-O, intensive conversion testing, either by hand or using scripts, was conducted on XML/EAD finding aids and XML/EAC-CPF authority records to ensure that RiC-O is usable with existing descriptive metadata. An open source conversion software was also developed and made available in April 2020. While some existing metadata sets may have a very fine level of granularity and accuracy, already using, for example, controlled vocabularies, or describing curation events separately, often these metadata don’t have the very precise structure that RiC-CM recommends. Even then, such a conversion process remains possible. In order to allow this, RiC-O sometimes provides several methods for representing information (as described below). From this point of view, RiC-O v1.0 may be considered a transitional ontology, in which some components may be deprecated later on. The usability of a model also depends on its documentation. RiC-O is documented extensively. The documentation will be reviewed and updated on a continuing basis. 3. RiC-O provides a flexible framework. This is a very important principle too. It is related with the usability principle quoted above. Moreover, archival description is flexible by essence. It is quite commonly noted that today the level of granularity of information varies from one finding aid to another (or from one authority record to another), or even within the same finding aid. Some series or agents are described summarily because little is known about them and there is little time for extensive research, while other series, even records, or agents are described in detail; some relations (e.g. that relating to provenance) may be described without any detail while others may be thoroughly documented, as ISAAR(CPF) and EAC-CPF allow it. Being generally flexible, for an OWL ontology, depends first on the polyhierarchical systems of classes and properties it provides. A superproperty or superclass, more general or generic than its subproperties or subclasses, must exist and be available for handling information, while at the same time more accurate subcomponents must be there for handling more accurate description. Also, RiC-O provides methods for describing relations as full entities, as well as direct and short paths between entities. 4. RiC-O opens new potential for archival description. Linked Data tools and interfaces enable end users to go through RDF/RiC-O graphs, query them using SPARQL, and make inferences. This means a completely new way of consulting archival metadata and their multiple contexts. An end user should be able to ask of any given data set, for example, “What are (according to your dataset) the corporate bodies that succeeded a given entity from its end of existence to now (as concerns this given activity)?”, or “what instantiations of this photograph exist?”, or “what are the existing copies of this original charter?”, and get a list of these entities. This means that institutions or projects that invest in the implementation of RiC-O will be able to query their data in ways not possible with the previous ICA standards, and will get new insight into the content and context of their archives that wasn’t visible with the existing ICA-standards. What is more, repositories using RiC-O may infer new assertions from the RDF datasets and link them to other resources outside their institution, thereby amplifying the query and inferencing possibilities manifold. 5. RiC-O is extensible. Institutions with descriptive needs beyond what RiC-O provides out-of-the-box have the option of extending the ontology by adding new subclasses or subproperties as needed. Also, the concepts defined in existing SKOS vocabularies (e.g. a list of documentary form types) can also be connected to RiC-O based graphs (using the *Type classes, and properties which are in the domain or range of these classes). RiC-O has also the potential to be usable in other contexts than purely archival ones. It can be used to “hook” archival description to descriptive metadata in other domains (e.g. bibliographic or museum metadata). As said above, alignment with other models will be undertaken by EGAD in a future revision cycle, facilitating such connections. Understanding RiC-O: a quick overview of some features From RiC-CM to RiC-O 1. From RiC-CM components to RiC-O classes Each RiC-CM entity has a corresponding class in RiC-O. These classes are organized according to the same hierarchy as in RiC-CM. Some projects may need very few of them (e.g. Agent, Record Resource and Activity only), while others may need more (e.g. Corporate Body and Person; Record; Place; Organic Provenance Relation). Many classes only exist in RiC-O and not in RiC-CM. These additional classes address special needs: some correspond to RiC-CM attributes, when it may be considered necessary to handle them as full entities. This is the case for Type and its subclasses, that correspond to RiC-CM attributes that contain controlled values, and that can help to articulate RiC-O with external RDF resources like SKOS vocabularies; and also for Language, Name and Identifier, that can be considered as full entities and as key linking nodes in a RDF graph. All these classes have been grouped under a Concept class. some classes have been added in order to provide a more accurate definition and model for some entities. Place thus comes along with a Physical Location class, and with a Coordinates class. A Place is considered both a geographical and historical entity. As a historical entity, among other features, it has a history, and may be preceded or succeeded by other Places. A Place also may have zero to many Physical Location through time (for instance, its boundaries, if it is an administrative area or a country, may change). Each Physical Location may be connected to zero to many Coordinates. This model is quite close to the Linked Places Format (https://github.com/LinkedPasts/linked-places). Another example of such an addition is the Proxy class, that represents (stands for) a Record Resource as it exists in a specific Record Set. finally, a system of n-ary classes helps to implement the Relations section of RiC-CM. While these relations also are represented as simple, binary object properties (e.g. hasOrganicProvenance that corresponds to RiC-R026 relation), you may need to assign different attributes to a relation, e.g. a date, certainty or description, as it is already possible, and quite often done, in a XML/EAC-CPF file. One of the standard available methods for representing such a documented relation in RDF for now is to use a class. The RDF-star specification, which is being developed by the W3C RDF-DEV Community Group, provides a far simpler method (allowing to consider a triple as the subject or object of another triple; see https://w3c.github.io/rdf-star/) and is already being used by some tools; however it is not yet a complete W3C standard. Thus, for example, in RiC-O a OrganicProvenanceRelation class exists. This class may connect one to many Agents to one to many created or accumulated Record Resources or Instantiations, and has some specific object properties (certainty, date, description, source). Back to the hasOrganicProvenance object property, let us add that it is formally defined in RiC-O, using OWL 2 property chain axiom (see https://www.w3.org/TR/owl2-new-features/#F8:_Property_Chain_Inclusion), as a ‘shortcut’ for the longer path ‘thingIsSourceOfRelation/organicProvenanceRelation_role/relationHasTarget’, where the intermediate node is an instance of OrganicProvenanceRelation: A triplestore, with the appropriate configuration, may thus infer the direct ‘hasOrganicProvenance’ assertion from this long path. 2. About RiC-O datatype properties (relations whose object is a litteral) Most of the datatype properties in RiC-O correspond to RiC-CM attributes that contain free, plain text. See for example rico:generalDescription, rico:history and rico:scopeAndContent. In many simple usecases it’s sufficent to just use the rico:identifier or rico:name datatype properties. However, in addition to these datatype properties, the Name and Identifier RiC-CM attributes also have corresponding classes (subclasses of rico:Appellation). A resource may have several Identifiers (e.g. archival reference code, system number, digital object identifier) or Names and each comes with different attributes; in this case instances of classes are needed. The Location RiC-CM attribute also has a rico:PhysicalLocation corresponding class (for users who want to use Place, Physical Location and Coordinates for handling places). As already said too, every RiC-CM attribute that has ‘controlled value’ or ‘rule-based’ as a schema value, has a class as corresponding component in RiC-O. However, for these CM attributes that correspond to a RiC-O class, as it is necessary to provide an immediately usable ontology, two supplementary datatype properties exist that allow not to use the classes, at least for a while, if you want to implement RiC-O and create RiC-O/RDF datasets from existing archival metadata without being able to handle URIs for the information you have. For example, you may not be able to handle and maintain URIs for some controlled values you use in EAD finding aids for carrier types: maybe your information system does not use a vocabulary for this, and you cannot for a while consider these carrier types as full entities. Nevertheless you want to produce RiC-O datasets where every piece of information is kept, and you want to avoid blank nodes. If RiC-O would only provide the Carrier Type class, it would be an issue for you. So RiC-O provides a rico:type datatype property, with range rdfs:literal, which allows you to move forward. For RiC-CM Coordinates attribute, you also have the rico:geographicalCoordinates datatype property. These datatype properties have a skos:scopeNote which says (for example) "Provided for usability reasons. May be made deprecated or removed later on. Use only if you don’t use Physical Location and Coordinates classes with Place." The same key design principle (RiC-O must be immediately usable) led us to define some datatype properties that would enable users to use RiC-O in simple usecases where they do not want to consider dates and rules as full entities. Thus, there of course is Date and Rule classes in RiC-O (since there are Date and Rule entities in RiC-CM). And you also have a rico:date datatype property, which has several subproperties; plus a rico:ruleFollowed datatype property. The same analysis led us to keep the rico:history datatype property in RiC-O (same as RiC-CM history attribute), while RiC-CM and RiC-O also provide the Event class, and using a series of Events may of course be a better method, easier to query, link and display, than simply using a history prose discourse. The two methods may be used in parallel within the same dataset by an institution that, for example, would decide to emphasize only the accession, appraisal and description events among the whole history of Record Resources. These datatype properties have the same kind of skos:scopeNote as above. Finally, we have introduced a few datatype properties that do not correspond to any RiC-CM attribute. Some are superproperties, and thus group datatype properties: rico:physicalOrLogicalExtent, with rico:carrierExtent, rico:instantiationExtent and rico:recordResourceExtent as subproperties; rico:textualValue, with rico:expressedDate, rico:normalizedValue and rico:quantity as subproperties; rico:measure; rico:referenceSystem. Some are simply more specific properties: rico:accrualsStatus; rico:recordResourceStructure and rico:instantiationStructure, subproperties of rico:structure; rico:title (subproperty of rico:name); rico:altitude, rico:height, rico:latitude, rico:length, rico:longitude, rico:width (subproperties of rico:measure), rico:geodesicSystem and rico:altimetricSystem (subproperties of rico:referenceSystem). 3. About RiC-O object properties (relations between two entities) In order to connect all the classes created, a significant number of object properties have been defined, in addition to the 85 relations defined in RiC-CM 1.0. While the 'flat' list of object properties is a long one, the object properties are grouped hierarchically, so that one can use the upper to intermediate level ones for simplicity sake, or choose the most accurate and expressive ones, or extend the system adding a subproperty easily. It is expected that, in most use cases, a subset of these properties only will be needed. Below we just give a few details on certain specific sets of properties. While in RiC-CM it was not possible to achieve such a level of precision with simple attributes, RiC-O includes object properties to assert that a rico:RecordSet has or had members (either all of them, or some of them) that share some characteristics, i.e. Language, ContentType, DocumentaryFormType, LegalStatus, or RecordState. See for example rico:hasOrHadAllMembersWithCategory, and its subproperties. Some of the object properties are formally defined as shortcuts: they can be inferred if you create triples that include instances of the Relation classes. See the example explained above in the section dedicated to classes. Many properties, new in RiC-O 1.0, are transitive, as explained in the history note above. 4. Named Individuals RiC-O adds six individuals to address current and frequent needs: FindingAid and AuthorityRecord, which are instances of both RiC-O Documentary Form Type and SKOS Concept. They can be used for categorizing Records, finding aids and authority records being considered as Records. For example, a Record with Documentary Form Type ‘Finding Aid’ may be connected to one to many Record Resources using the 'rico:describes’ object property. Fonds, Series, File, and Collection are instances of both Record Set Type class and skos:Concept. Their definition is taken from the ISAD(G) glossary. They can be used for categorizing Record Sets. We expect other categories to be defined by the archival community as RiC-O matures, forming rich, hopefully multilingual, SKOS vocabularies that support rich description (for example, allowing an instance of the Documentary Form Type class to have a history and temporal relations to other documentary form types). RiC-O documentation and annotation properties Each class or property has an English, a French and a Spanish label (rdfs:label), and a description (rdfs:comment). Some also have a skos:scopeNote or a skos:example. When a RiC-O class or property corresponds to a RiC-CM component in any way, its description and scope note are either the same as or derived from their RiC-CM definition and scope note. RiC-O provides two annotation properties (subproperties of rdfs:comment) for handling: information about the corresponding RiC-CM component when applicable (rico:RiCCMCorrespondingComponent). Various phrasings are used in this property depending on the rule applied for defining the RiC-CM component. information about possible mappings with other models or ontologies (rico:closeTo, rarely used in this 1.0.2 version)). Any change in the definition of a class or property made since December 2019 is documented using a skos:changeNote. Next steps The following is a non exhaustive list of known issues, topics or tasks on which EGAD has begun to work and will continue to work in the next months. articulate the Event and Activity classes, and the Relation system of classes add suggestions of mappings (in rico:closeTo) and OWL equivalences between some classes or properties and components in other models (among which - this is not an exhaustive list- PREMIS, Schema.org, PROV-O, IFLA-LRM and RDA, CIDOC-CRM), or document how these models can be used together.
International Council on Archives Records in Contexts Ontology (ICA RiC-O) version 1.0.2
RDB to RDF Mapping Language - Vocabulary
This vocabulary extends the data cube vocabulary to support publication of statistical data in RDF, using an information model based on SDMX
Vocabulary for publishing SDMX statistical data in RDF
This vocabulary defines terms used in SHACL, the W3C Shapes Constraint Language.
W3C Shapes Constraint Language (SHACL) Vocabulary
This document describes the RDFS vocabulary description used in the Shape Expression Language (ShEx) shex-semantics along with the default JSON-LD Context and shape expression to validate RDF versions of shapes.
This shapes graph can be used to validate SHACL shapes graphs against a subset of the syntax rules.
SIOC (Semantically-Interlinked Online Communities) is an ontology for describing the information in online communities. This information can be used to export information from online communities and to link them together. The scope of the application areas that SIOC can be used for includes (and is not limited to) weblogs, message boards, mailing lists and chat channels.
An RDF vocabulary for describing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, 'folksonomies', other types of controlled vocabulary, and also concept schemes embedded in glossaries and terminologies.
The Solid Terms vocabulary defines terms referenced in Solid specifications.
This ontology is based on the SSN Ontology by the W3C Semantic Sensor Networks Incubator Group (SSN-XG), together with considerations from the W3C/OGC Spatial Data on the Web Working Group.
Sensor, Observation, Sample, and Actuator (SOSA) Ontology
QUDT Vocabulary - Systems of Units - v2.1.25
This ontology describes sensors, actuators and observations, and related concepts. It does not describe domain concepts, time, locations, etc. these are intended to be included from other ontologies via OWL imports.
This document describes a vocabulary for annotating descriptions of vocabularies with examples and usage notes.
VANN: A vocabulary for annotating vocabulary descriptions
An RDF vocabulary for relating SW vocabulary terms to their status.
VSO: The Vehicle Sales Ontology A Web vocabulary for describings cars, boats, bikes, and other vehicles for e-commerce. Vocabulary: http://purl.org/vso/ns Namespace: http://purl.org/vso/ns# The Vehicle Sales Ontology is designed to be used in combination with GoodRelations, a standard vocabulary for the commercial aspects of offers for sale or rental. See http://purl.org/goodrelations/ for more information.
VSO: The Vehicle Sales Ontology for Semantic Web-based E-Commerce
This file specifies the set of classes and properties used in the RDF/OWL version of POWDER documents.
A vocabulary for representing latitude, longitude and altitude information in the WGS84 geodetic reference datum. Version $Id: wgs84_pos.rdf,v 1.22 2009/04/20 15:00:30 timbl Exp $. See http://www.w3.org/2003/01/geo/ for more details.
WGS84 Geo Positioning: an RDF vocabulary
This ontology is based on work initiated at Dagstuhl Schloss in September 2011
XKOS: an SKOS extension for representing statistical classifications