dataesr/scientific-paragraphs-categorization huggingface dataset:
We measure its impact on facilitating ontology descriptions, identification and selection. In the following, we will review the current practices related to describing ontologies and using ontology metadata vocabularies. We have observed some limitations, lack of harmonization and confusions in the practices. This is not surprising when considering the efforts needed to just identify the potentially relevant vocabularies that could be used to describe ontologies. 1 Indeed, a few of these vocabularies are dedicated to ontologies and vocabularies (e. g. , OMV, DOOR, VOAF), or datasets (e. g. , VOID, DCAT, SCHEMA) and others capture more general metadata (e. g. , DC, DCT, PROV, DOAP). 2 They are often not maintained anymore, sometimes very specific or too general and of course, they are rarely aligned one another despite their significant overlaps.
In the rest of the paper, we will adopt a definition of metadata including anything that can be said to describe an ontology, structured data or free descriptions: how and why it is built, used, changed, accessed and how it relates to other ontologies and datasets. That will include properties going from (1) intrinsic properties, e. g. , name, URI, creation date; (2) relation to other ontologies, e. g. , imports, 1 In this paper, we will consider the terms ontologies, terminologies, thesaurus and vocabularies as the type of knowledge organization systems  [42]  or knowledge artifacts  [41]. Those are the subjects we are interested in describing. However, to facilitate the reading, we will use the word ontology to identify the subject that is described by metadata (e. g. , Movie Ontology, Human Disease Ontology, MeSH thesaurus, etc.
discussion in Sect. 7. 1). Our objective was to address the need of a common metadata model inside an ontology repository, i. e. , implementing a way to compare ontologies side by side and describe the global landscape of all the ontologies in a library or repository. The list proposed has been built following an analysis of current ontology metadata practices: • We have reviewed the most standard and relevant vocabularies (23 totals, e. g. , Dublin Core, VOID, Ontology Metadata Vocabulary, Data Catalog Vocabulary, etc. ) to describe metadata for ontologies. For each of these vocabularies, we have selected the significant properties to describe objects that an ontology could be considered a certain type of, e. g. , dataset, an asset, a project or a document. For instance, an ontology may be seen as a prov:Entity object and then the property prov:wasGeneratedBy may then be used to describe its provenance.
g. , thesaurus, ontology, taxonomy, terminology, etc. ). We also have properties to capture information such as licenses, ontology editor used, syntax, etc. We can also capture how ontologies are related to other resources (web site, publication, wiki, datasets, etc. ) and other ontologies. Most metadata are automatically extracted from the original ontology file, if present, when the ontology is uploaded to the portal. Or it can be in some cases automatically generated by the portal. We have completely refactored the AgroPortal ontology metadata edition page to facilitate the job to ontology developers when uploading an ontology to the portal and manually editing metadata. With a new edition interface and a common model available for all the ontologies in the portal, we have then spent a significant amount of time to edit and curate ourselves ontology descriptions, and we have asked the ontology developers to validate our edits and complete them.
Capturing the metadata about "electronic objects" has been the original motivation of the DCMI  [37]  and multiple standardization bodies. 5 The Dublin Core (DC) and DCMI Metadata Terms (DCT) are the results of these initiatives. Today, semantically rich metadata is identified as one of requirements to produce FAIR data  [5]  and it becomes the core mission of research projects such as the Center for Expanded Data Annotation and Retrieval  [38]  which tackles the challenge of authoring and predicting biomedical datasets metadata. An important effort has been made in the recent years to define vocabularies for datasets. The Semantic Web Health Care and Life Sciences (HCLS) working group of the W3C have produced a community profile which reviews many of them and proposes a set of recommendations when describing datasets  [39].
The FAIRsharing. org action also builds a database of "data and metadata standards, inter-related to databases and data policies"  [40]  to which AgroPortal's content is now automatically pushed. More recently, the BioSchemas initiative (http://bioschemas. org) has also started a community effort to extend Schema. org with metadata properties that would be relevant for life sciences data. Although we do believe ontologies can somehow be seen as "datasets"-often the closest objects in vocabularies-they have some particularities that require more specific metadata vocabularies as we will see Sect. 5. 2. Ontologies are some kind of knowledge artifacts  [41]  or knowledge organization systems  [42]. Efforts have been made to develop metadata vocabularies or application profiles adapted to such systems, for example, the Networked Knowledge Organization Systems (NKOS) working group  [43]  or the Ontology Metadata Vocabulary working group  [44]  which results will be further commented later.
This community effort on identifying the useless or ambiguous element from OMV proposed a few small changes but went no further. 6 ntologies share some characteristics with web datasets or data catalogs. Indeed, in the semantic web vision, ontologies are themselves sets of RDF triplets. We thus argue that some properties that have been defined to describe web datasets are relevant to ontologies also. Among the recent work to describe "datasets," there are: the Vocabulary of Interlinked Datasets (VOID) [52], a W3C Note proposed in 2011 which can be used "to express general metadata based on DC, access metadata, structural metadata, and links between datasets. " VOID allows to describe two main objects void:Dataset and void:Linkset which are sets of links between datasets. The vocabulary also includes URIs for license or serialization formats.
Identifiers. org (IDOT)  [53]  is a small vocabulary intended to "referencing of data for the scientific community, with a current focus on the Life Sciences domain. " It was developed by the European Bioinformatics Institute to specify, among other things, URI patterns. The Data Catalog Vocabulary (DCAT), which is the most recent W3C Recommendation for metadata (and uses DCT) and its profile, Asset Description Metadata Schema (ADMS), used to describe semantic assets (data models, code lists, taxonomies, dictionaries, vocabularies) created by the EU's Interoperability Solutions for European Public Administrations (ISA). Finally, Schema. org has been proposed and adopted in 2011 by Google, Bing and Yahoo! and do include a dataset class. To describe other kinds of resources, one will find the following vocabularies: Friend of a Friend Vocabulary (FOAF) or Description of a Project (DOAP) to describe documents and projects.
The Protocol for Web Description Resources (POWDER) provides a mechanism to describe and discover web resources. The DDI-RDF Discovery Vocabulary (DISCO) which is a vocabulary to describe studies. The Information Artifact Ontology (IAO)  [56] , which was defined for representation of types of information content entities such as documents, databases, and digital images. The Semanticscience Integrated Ontology (SIO)  [57]  which describes many different types of informational entities and relations between them. [58]  have proposed a metadata vocabulary for the Lemon model  [59]  called LInguistic Metadata (LIME) for describing linguistic resources and linguistically enriched datasets. Finally, we must also mention the document ISO/IEC 19763-3 (Metamodel framework for interoperability (MFI)-Part 3: metamodel for ontology registration) which latest version is from 2010 and is not public.
Method to Select Properties from Existing Vocabularies Enlightened by the analysis presented in the previous section, we have accomplished a systematic review (as methodologically described by  [64] ) of the vocabularies previously identified with the following research question in mind: Which existing properties could be used to describe ontologies? The previously listed vocabularies have been identified from: (1) the semantic web literature; (2) investigating ontology libraries; (3) related similar studies such as the one for dataset by the HCLS working group. Vocabularies were selected based on their degree of standardization, relevance for ontologies and current usage by ontology developers. The final list of the 23 reviewed vocabularies and the numbers of property reused are available in Table  3 , plus the NCBO Bio-Portal metadata model that we used as baseline and listed as a vocabulary with the prefix "bpm.
The criteria for inclusion were the following, considered by order of importance: 16 The study reported 3 only, but the case of MMI was a mistake. 1. Relevance for describing an ontology-the property may have a sense if used to describe an ontology. 2. Being not "specific" to a library-even if the ontology library helps to populate or predict the property, the property would capture an information that belongs to the ontology. For instance, properties such as credentials on the portal or maintenance information, or local parsing status are considered "specific. " 3. Semantic consistency-there must not be any conflict (e. g. , disjoint classes) if someone would describe an ontology with all the listed properties. For instance, an ontology may be an instance of omv:Ontology, void:Dataset and cc:Work at the same time.
4. Being a W3C or Dublin Core Recommendations. 5. The frequency of use in the study presented in Sect. 4. 2. 6. Priority to vocabularies specific for ontologies rather than to the ones specialized for more general object (cc:Work, dcat:DataSet, sd:Service, etc. ). Although we agree dereferenceability is an important criterion for a vocabulary, we have not excluded properties that are not dereferenceable, even it means a machine would hardly understand the semantics of the property. We will mention this as a requirement for a future ontology metadata vocabulary in Sect. 7. 1.
Properties Selected from Existing Metadata Vocabularies For each of these vocabularies, we have selected the significant properties to describe objects that an ontology could be considered a certain type of, e. g. , a dataset, an asset, a project or a document. For instance, an ontology may be seen as a prov:Entity object and then the property prov:wasGeneratedBy may then be used to describe its provenance. We illustrate with examples as often as possible. The first things to look at are the properties available in the W3C standard vocabularies, such as RDFS, OWL, and SKOS. Indeed, they include some annotation properties that we can use to describe ontologies if we consider them instances of rdfs:Resource, owl:Ontology or skos:conceptScheme. rdfs:label, rdfs:seeAlso, rdfs:comment, owl:versionInfo, owl:versionIRI, owl:imports, owl:priorVersion, owl:backwardCompatibleWith, owl:incompatibleWith, owl:deprecated, skos:prefLabel, skos:altLabel, skos:hiddenLabel, skos:hasTopConcept, skos:notation SKOS label properties can be used to denote the alternative or non-conventional names of an ontology.
For instance, International Classification of Diseases, 10th revision (ICD-10) has for prior version ICD-9 and for specialization ICD-10-CM (Clinical Modification made by US National Center for Health Statistics). From NKOS Application Profile, we have selected 4 properties among the 6 new ones defined in the namespace and have in that case considered the properties would be applied to rdfs:Resource. Two have been excluded because we already have more precise properties in other vocabularies (nkos:serviceOffered and nkos:sizeNote). nkos:alignedWith, nkos:basedOn, nkos:updateFrequency, nkos:usedBy Among the metadata vocabularies to describe datasets, we have reviewed VOID, a W3C Note proposed in 2011 to describe RDF datasets. It allows describing two main objects void:Dataset and void:Linkset which are set of links between datasets.
The vocabulary also includes URIs for license or serialization formats. void:Dataset can be described with 24 properties including a few metrics plus some from DCT. From VOID, we picked-up 16 relevant properties. void:subset, void:classPartition, void:propertyPartition, void:rootResource, void:classes, void:properties, void:triples, void:entities, void:exampleResource, void:vocabulary, void:sparqlEndpoint, void:dataDump, void:openSearchDescription, void:uriLookupEndpoint, void:uriRegexPattern, void:uriSpace For instance, void:uriRegexPattern may be used to explain the pattern that some ontologies use when building their URIs and concept identifiers, e. g. , (ICD-10)'s codes respect a structure that keeps track of the chapter, and hierarchy (K70. 3 code for "Alcoholic cirrhosis of liver" is the 3rd of "Alcoholic liver disease" (K70) which are all in the "Diseases of the digestive system" Chapter (K)).
A few of the properties from Indentifiers. org (IDOT)  (6)  shall be relevant to describe ontologies also: idot:state, idot:obsolete, idot:alternatePrefix, idot:identifierPattern, idot:preferredPrefix, idot:exampleIdentifier VANN is a small vocabulary created to describe vocabularies, which includes: vann:preferredNamespacePrefix, vann:preferredNamespaceUri, vann:usageNote, vann:example, vann:changes The property idot:preferredPrefix or vann:preferredNamespacePrefix can be used to store the preferred prefix when using the ontologies. See for example, http://prefix. cc for all possible prefix values. DCAT is the W3C Recommendation since January 2014 to describe data catalogs; it offers a dcat:Dataset class relevant for ontologies. DCAT uses DCT and also offers properties with domain dcat:Distribution, but we have not taken those ones to restrict our selection to the dcat:Dataset class (among the 4 missed properties, 3 finds equivalent in other vocabularies).
The adms:translation can be used for this. Schema. org (SCHEMA) can describe multiple types of resources. We have identified the schema:Dataset type as the closest one to describe ontologies. Schema. org is very rich to describe schema:Dataset (including properties inherited of schema:CreativeWork and schema:Thing), we have identified 41 relevant properties: schema:distribution, schema:includedInDataCatalog, schema:spatial, schema:about, schema:alternativeHeadline, schema:associatedMedia, schema:audience, schema:author, schema:award, schema:comments, schema:contributor, schema:copyrightHolder, schema:creator, schema:dateCreated, schema:dateModified, schema:datePublished, schema:workExample, schema:fileFormat, schema:hasPart, schema:isPartOf, schema:inLanguage, schema:isBasedOn, schema:keywords, schema:license, schema:mainEntity, schema:publisher, schema:publishingPrinciples, schema:review, schema:schemaVersion, schema:sourceOrganization, schema:translator, schema:version, schema:alternateName, schema:description, schema:image, schema:mainEntityOfPage, schema:citation, schema:name, schema:url, schema:translationOfWork, schema:translation For instance, the property schema:includedInDataCatalog may be used to store the fact that an ontology is hosted in different ontology libraries.
This is, for instance, the cases for the OBO Foundry ontologies that are, in addition of the foundry being uploaded in NCBO BioPortal, Ontobee, OLS and AberOWL. With such a property properly populated, everyone will always know in which library to find an ontology. If we consider an ontology as different kinds of objects, additional relevant vocabularies may be used. Thus, FOAF can be used to describe an ontology as an instance of foaf:Document, DOAP if an ontology is viewed as development project (doap:Project) and CC to see it as a cc:Work 18  : foaf:name, foaf:homepage, foaf:isPrimaryTopicOf, foaf:page, foaf:primaryTopic, foaf:maker, foaf:topic, foaf:depiction foaf:logo, foaf:fundedBy, doap:name, doap:blog, doap:language, doap:wiki, doap:release, doap:description, doap:created, doap:download-page, doap:helper, doap:maintainer, doap:translator, doap:audience, doap:download-mirror, doap:service-endpoint, doap:screenshots, doap:repository, doap:bug-database, doap:mailing-list, cc:attributionName, cc:attributionURL, cc:license, cc:morePermissions, cc:useGuidelines More and more ontology developers have turned to GitHub to store and release their ontologies, for example, the Environment Ontology (https://github.
com/EnvironmentOn tology). The DOAP properties are thus very relevant to capture the metadata about the ontology development project. Two vocabularies for representing provenance information are included: PROV and PAV. PAV specializes terms from PROV and DCT. It contains 40 properties (including 30 specific ones) with no constraint on range or domain. When incorporating PROV and PAV, we had to focus on the main properties offered to describe prov:Entity (but potentially more maybe used): prov:generalizationOf, prov:generatedAtTime, prov:wasAttributedTo, prov:wasInfluencedBy, prov:wasDerivedFrom, prov:wasRevisionOf, prov:specializationOf, prov:invaliatedAtTime, prov:wasGeneratedBy, prov:wasInvalidatedBy, pav:hasCurrentVersion, pav:hasVersion, pav:version, pav:createdOn, pav:authoredOn, pav:contributedOn, pav:lastUpdateOn, pav:contributedBy, pav:authoredBy, pav:createdBy, pav:createdWith, pav:previousVersion, pav:hasEarlierVersion, pav:derivedFrom, pav:curatedBy, pav:curatedOn From the OboInOwl specification, we took 9 of the 13 properties (and the alternative names, not listed, e.
Existing Properties in Ontology Repositories In order to manage versioning, access rights and metadata, BioPortal model stores ontologies with two objects: one Ontology which is actually the shell for multiple Submissions that contains the real content of an ontology. The Ontology object contains the most usual metadata (name, acronym, administrators, viewing restriction, group and categories) that will remain over versions, whereas the Submission objects contain the detailed metadata (description, metrics, contact, etc. ) and links to the actual content of that specific version. For example, the following REST service calls will return, respectively, the Ontology object and the latest Submission for the NCI Thesaurus: http://data. bioontology. org/ontologies/NCIT?display=all http://data. bioontology.
classes, bpm:metrics. individuals, bpm:metrics. properties, bpm:metrics. maxDepth, bpm:metrics. maxChildCount, bpm:metrics. averageChildCount, bpm:metrics. classesWithOneChild, bpm:metrics. classesWithMoreThan25Children, bpm:metrics. classesWithNoDefinition, bpm:downloadRdf, bpm:downloadCsv Once a primary version of the list was created from Bio-Portal plus the standard metadata vocabularies, we also analyzed the other ontology repositories. We did not find other properties that were not already covered by our review so far. From the OBO Foundry, the only exceptions were the properties inside the obofmd namespace (non-dereferenceable), that seems to be the ones the OBO Foundry developers did not find in any vocabulary. Although we have matches for 4 over 5 of these properties, we did not integrate those by the lack of information about them (plus this namespace was not identified in Sect.
For instance, the user interface will offer a pop-up menu to select the relevant license (CC, BSD, etc. ) while the corresponding URI will be taken from the RDFLicense dataset (http://rdflicense. appspot. com). Knowledge organization systems types are taken from the NKOS Types Vocabulary of the Dublin Core initiative. 24 Natural languages are taken from the LEXVO vocabulary  [66]. Ontology syntax values are provided by the W3C. 25  Some other values (the type of ontology or formality level) are taken as individuals from OMV. An example using the OntoBiotope ontology metadata page in AgroPortal is shown in Fig. 1. • Advanced ontology search and selection thanks to Agro-Portal's Browse Ontologies page (Fig. 2 ) which offers a convenient user interface with sorting, filtering, and facets that facilitate the identification of the ontology(ies) of interest.
Conclusion and Future Work In this paper, we have shown the impact of unified and harmonized metadata within an ontology repository. We have explained how it facilitates ontology description, selection and helps to capture the global landscape of ontologies from a given domain. Thanks to this new unified model served by a stable API, metadata descriptions of AgroPortal ontologies have already been automatically harvested by two external ontology libraries: the Agrisemantics Map of Data Standards (http://vest. agrisemantics. org) and FAIRsharing (http://fairs haring. org). Our motivation was first to make a review of the available vocabularies to describe ontologies or other kinds of resources (dataset, vocabulary, project, document) and pick up the properties that would be relevant for describing ontologies.
Acknowledgements This work is partly achieved within the  Semantic Indexing of French biomedical Resources  (SIFR-www. lirmm. fr/sifr) project that received funding from the  French National Research Agency  (Grant  ANR-12-JS02-01001 ), the  European Union 's  Horizon 2020 research and innovation program  under the  Marie Sklodowska-Curie Grant  agreement No  701771 , the  NUMEV Labex  (Grant  ANR-10-LABX-20 ), the  Computational Biology Institute of Montpellier  (Grant  ANR-11-BINF-0002 ) as well as by  University of Montpellier  and the  CNRS. This work has also been partially funded by the  Indian Statistical Institute  under the  Start-Up Grant  project. We also thank the  National Center for Biomedical Ontologies  for help and time spent with us in deploying the AgroPortal and all our users who have taken some time to author/review the metadata of their ontologies and answer our appreciation survey.
w3. org/2002/07/owl# owl:Ontology 11 2 pav http://purl. org/pav/ prov:Entity 30 2 prov http://www. w3. org/ns/prov# prov:Entity 22 2 rdfs http://www. w3. org/2000/01/rdf-sc rdfs:Resource 7 0 hema# schema http://schema. org/ schema:Dataset 90 7 sd http://www. w3. org/ns/sparql-servi sd:Service 13 1 ce-description# skos http://www. w3. org/2004/02/skos/c skos:conceptScheme 14 1 ore# vann http://purl. org/vocab/vann/ rdfs:Resource 6 3 voaf http://purl. org/vocommons/voaf# voaf:Vocabulary 16 5 void http://rdfs. org/ns/void# void:Dataset 24 5 bpm http://data. bioontology. org/metadat bpm:Ontology 36 34 a bpm:OntologySubmission Total 522 127.
When the list is small, this exact algorithm should not be significantly slower than the heuristic one. Unfortunately, computing bitwise operations cannot be efficiently done on RRR compressed bitvectors. To support the large query algorithm, the bitvectors are compressed using the Roaring  [5]  scheme (abbreviated ROAR). Roaring bitmaps are compressed using a hybrid technique that allows them to efficiently support set operations on bitvectors (intersection, union, difference, etc). However, we found that they generally do not compress as well as RRR on our data, leading to longer I/O times. In cases where both small and large queries are common, and query time is more important than disk space, both a ROAR and an RRR compressed tree can be maintained. We implemented SBT-ALSO, building on the SBT-SK code base  [1].
Acknowledgments:  Marwan Fahs  acknowledges the financial support of the  Partenariats Hubert Curien (PHC)  via the project  CEDRE  ( 35369WE ). Behzad Ataie-Ashtiani  and  Craig T. Simmons  acknowledge support from the  National Centre for Groundwater Research and Training ,  Australia. Behzad Ataie-Ashtiani  also appreciates the support of the Research office of the  Sharif University of Technology, Iran. The FORTRAN source code developed in this study is can be obtained by contacting the corresponding author ( Marwan Fahs ) at fahs@unistra. fr.