SKOSSupport - Revision history

Graybeal: added concrete example

2020-09-18T10:17:37Z

added concrete example

JenniferVendetti: Separate out skos:broader into it's own section

2017-12-04T22:30:47Z

Separate out skos:broader into it's own section

JenniferVendetti at 20:27, 4 December 2017

2017-12-04T20:27:36Z

JenniferVendetti at 20:19, 4 December 2017

2017-12-04T20:19:51Z

JenniferVendetti: Rewrite Metrics section

2017-12-04T20:16:45Z

Rewrite Metrics section

JenniferVendetti at 19:43, 4 December 2017

2017-12-04T19:43:57Z

JenniferVendetti at 19:31, 4 December 2017

2017-12-04T19:31:43Z

JenniferVendetti: /* skos:Concept */

2017-12-04T19:28:58Z

skos:Concept

JenniferVendetti: /* skos:ConceptScheme & skos:hasTopConcept */

2017-12-04T19:11:57Z

skos:ConceptScheme & skos:hasTopConcept

Jonquet at 18:34, 3 December 2017

2017-12-03T18:34:23Z

← Older revision		Revision as of 10:17, 18 September 2020
Line 85:		Line 85:

	At this time, BioPortal doesn't use SKOS mapping properties, i.e., skos:*Match, to populate the mapping repository. One-to-one mappings between SKOS concepts need to be uploaded separately via the [http://data.bioontology.org/documentation BioPortal REST API].		At this time, BioPortal doesn't use SKOS mapping properties, i.e., skos:*Match, to populate the mapping repository. One-to-one mappings between SKOS concepts need to be uploaded separately via the [http://data.bioontology.org/documentation BioPortal REST API].
		+
		+	=== Example of valid SKOS ===
		+
		+	This example provides a simple illustration of the composition of a SKOS file that complies with the above constraints.
		+
		+	==== Example header ====
		+
		+	The header shown here defines a few typical namespaces that may be useful.
		+
		+	The last namespace is the one that defines this SKOS vocabulary. Ideally, the IRI defining the myskosid namespace is the resolvable location of the SKOS ontology.
		+
		+	<?xml version="1.0" encoding="UTF-8"?>
		+	<rdf:RDF
		+	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
		+	xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
		+	xmlns:skos="http://www.w3.org/2004/02/skos/core#"
		+	xmlns:dct="http://purl.org/dc/terms/"
		+	xmlns:myskosid="https://example.org/ontologies/myskosontology/"
		+	>
		+
		+	==== Example ontology description ====
		+
		+	In the rdf:type item, this namespace is declared as the ConceptScheme. The ConceptScheme does not have to be the same as the namespace of the ontology.
		+
		+	Other metadata is provided as an example of good practices in ontology metadata. The dct:creator does not have to be an ORCID ID, but a unique identifier is an ideal way of naming a creator (whether individual or organization).
		+
		+	This ontology has only 2 concepts (to be defined below), hence only 2 skos:hasTopConcept declarations.
		+
		+	<rdf:Description rdf:about="https://example.org/ontologies/myskosontology/">
		+	<rdfs:label xml:lang="en">Example SKOS ontology for BioPortal</rdfs:label>
		+	<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#ConceptScheme"/>
		+	<rdfs:comment xml:lang="en">Example created to simplify understanding and creation of a SKOS vocab for BioPortal</rdfs:comment>
		+	<dct:created rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2020-09-16</dct:created>
		+	<dct:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2020-09-16</dct:modified>
		+	<dct:license rdf:resource="https://creativecommons.org/licenses/by/4.0/"/>
		+	<dct:creator rdf:resource="https://orcid.org/0000-0001-6875-5360"/>
		+	<skos:hasTopConcept rdf:resource="https://example.org/ontologies/myskosontology/fragmentid001"/>
		+	<skos:hasTopConcept rdf:resource="https://example.org/ontologies/myskosontology/fragmentid002"/>
		+	</rdf:Description>
		+
		+	==== Example term definitions ====
		+
		+	This section shows the two concepts and a few typical annotations about those concepts. The first rdf:Description line of each group names the concept that is being defined in the indented lines following.
		+
		+	The rdf:Type and skos:prefLabel are required annotation content for BioPortal to work effectively. Other items are optional.
		+
		+	The skos:topConceptOf is not strictly required for BioPortal SKOS ontologies, but provides useful contextualization if there is more than one topConcept.
		+
		+	<rdf:Description rdf:about="https://example.org/ontologies/myskosontology/fragmentid001">
		+	<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
		+	<skos:prefLabel xml:lang="en">First concept</skos:prefLabel>
		+	<skos:definition xml:lang="en">The very first example provided as part of this ontology.</skos:definition>
		+	<skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
		+	</rdf:Description>
		+	<rdf:Description rdf:about="https://example.org/ontologies/myskosontology/fragmentid002">
		+	<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
		+	<skos:prefLabel xml:lang="en">Second Concept</skos:prefLabel>
		+	<skos:definition xml:lang="en">The second example provided as part of this ontology.</skos:definition>
		+	<skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
		+	</rdf:Description>
		+
		+	==== Closing XML ====
		+
		+	Needed for a complete, parseable RDF file!
		+
		+	</rdf:RDF>

@@ Line 56: / Line 56: @@
-===== skos:broader hierachy =====
+==== Hierarchy in SKOS vocabularies ====
-For the hierarchy to be handle and display properly by BioPortal, hierarchical relations between skos:Concept need to defined by the skos:broader.
+The only semantic relationship in SKOS vocabularies that BioPortal uses to construct and display concept hierarchies is the skos:broader property.
-  ex:zebra rdf:type skos:Concept;
+  ex:mammals rdf:type skos:Concept;
-   skos:inScheme ex:animalThesaurus;
+  skos:prefLabel "mammals"@en;
-   skos:prefLabel "Plains zebra";
+  skos:broader ex:animals.
-   skos:altLabel "Equus quagga";
-   skos:broader ex:mammals.
+Other properties used to denote hierarchical relationships like skos:narrower, skos:broaderTransitive, and skos:narrowerTranstive, are ignored.

← Older revision		Revision as of 20:27, 4 December 2017
Line 83:		Line 83:


−	==== ~~Note on~~ mapping properties ====	+	==== SKOS mapping properties ====

−	~~As of now~~, skos:*Match ~~properties are parsed as any properties~~, ~~but will not be used~~ to ~~populated BioPortal's~~ mapping repository.	+	At this time, BioPortal doesn't use SKOS mapping properties, i.e., skos:*Match, to populate the mapping repository. One-to-one mappings between SKOS concepts need to be uploaded separately via the [http://data.bioontology.org/documentation BioPortal REST API].
−	One-to-one mappings between concepts need to be uploaded ~~aside using~~ the REST API.

← Older revision		Revision as of 20:19, 4 December 2017
Line 80:		Line 80:
	==== SKOS-XL ====		==== SKOS-XL ====

−	Currently BioPortal offers no support for the SKOS eXtension for Labels (SKOS-XL). A suggested workaround for SKOS vocabularies that make use of SKOS-XL, is to dump the value of labels (i.e., skosxl:literalForm of skosxl:Label instances) into the corresponding skos:Label property.	+	Currently BioPortal offers no support for the [https://www.w3.org/TR/skos-reference/#xl SKOS eXtension for Labels (SKOS-XL)]. A suggested workaround for SKOS vocabularies that make use of SKOS-XL, is to dump the value of labels (i.e., skosxl:literalForm of skosxl:Label instances) into the corresponding skos:Label property.

@@ Line 68: / Line 68: @@
-==== Note on metrics ====
+==== Metrics data for SKOS vocabularies ====
-[[File:Metrics.png|thumb|400px|PLOS Thesaurus metrics in BioPortal]]
+BioPortal uses the [https://owlcs.github.io/owlapi/ OWL API] for parsing all ontology and vocabulary submissions, as well as for the calculation of metrics data. The OWL API treats SKOS vocabularies as RDF files containing classes and instances. According to the SKOS Reference, concepts are [https://www.w3.org/TR/skos-reference/#L842 instances of owl:Class], and thus are counted as instances (a.k.a. "individuals").
-Because BioPortal's metrics are mostly being computed by the OWL-API, a SKOS vocabulary will be then treated like any RDF file with classes and instances. According to the SKOS specification, because skos:Concept are instances, they will be counted as "individuals" (not class).
+When viewing metrics tables in the BioPortal user interface, the value for the "NUMBER OF INDIVIDUALS" corresponds to the number of concepts in any given SKOS vocabulary.
-Therefore, when looking a the metrics, one shall consider that the number of individuals reports the number of concepts in the vocabulary and not the number of classes like this is the case with OWL format ontologies.

@@ Line 66: / Line 66: @@
     skos:altLabel "Equus quagga";
     skos:broader ex:mammals.
 ==== Note on metrics ====
@@ Line 74: / Line 75: @@
 Therefore, when looking a the metrics, one shall consider that the number of individuals reports the number of concepts in the vocabulary and not the number of classes like this is the case with OWL format ontologies.
-SKOS-XL extension of the SKOS format is currently not supported by BioPortal.
+==== SKOS-XL ====
-It is advised to dump the value of labels (i.e., skosxl:literalForm of skosxl:*Label instances) into the corresponding skos:*Label property.
 ==== Note on mapping properties ====

@@ Line 29: / Line 29: @@
 '''Note:''' Some OWL ontologies declare the SKOS namespace to facilitate minimal use of SKOS constructs for things like labels (e.g., skos:prefLabel, skos:altLabel) or mappings (e.g., skos:exactMatch, skos:broaderMatch). In these cases, the proper format for new ontology submissions is OWL, not SKOS.
 ===== skos:ConceptScheme & skos:hasTopConcept =====
@@ Line 53: / Line 54: @@
 If your vocabulary declares more than one concept scheme, all of the top concepts will be aggregated and displayed as root level concepts. BioPortal's user interface doesn't provide support for grouping top level concepts by concept scheme. It is recommended to declare a owl:Ontology, especially for metadata annotations.
 ===== skos:broader hierachy =====

@@ Line 20: / Line 20: @@
    <nowiki><http://www.example.com/animals></nowiki> rdf:type skos:Concept
-In SKOS vocabularies, BioPortal only treats the SKOS concept assertions as concepts to be displayed. If the vocabulary contains other assertions about other types of concepts, BioPortal will not treat these as concepts in any of its displays or features. See the W3C's SKOS System Primer and SKOS Reference for concept documentation and examples:
+In SKOS vocabularies, BioPortal only treats the SKOS concept assertions as concepts to be displayed. If the vocabulary contains other assertions about other types of concepts, BioPortal will not treat these as concepts in any of its displays or features.
 https://www.w3.org/TR/2009/NOTE-skos-primer-20090818/#secconcept
 https://www.w3.org/TR/skos-reference/#concepts
-If you declare the skos name space only for the purpose of using SKOS properties for label or mapping, it is not needed to select the SKOS format when uploading your ontology. Use the normal OWL format instead.
+'''Note:''' Some OWL ontologies declare the SKOS namespace to facilitate minimal use of SKOS constructs for things like labels (e.g., skos:prefLabel, skos:altLabel) or mappings (e.g., skos:exactMatch, skos:broaderMatch). In these cases, the proper format for new ontology submissions is OWL, not SKOS.
 ===== skos:ConceptScheme & skos:hasTopConcept =====

@@ Line 49: / Line 49: @@
 https://www.w3.org/TR/skos-reference/#schemes
-Note that if your vocabulary declares more than one skos:ConceptScheme, all the skos:hasTopConcept instances will be aggregated and consider the roots of your vocabulary.
+If your vocabulary declares more than one concept scheme, all of the top concepts will be aggregated and displayed as root level concepts. BioPortal's user interface doesn't provide support for grouping top level concepts by concept scheme. It is recommended to declare a owl:Ontology, especially for metadata annotations.
 ===== skos:broader hierachy =====