Ontology Dev Tools SOW Final.pdf

Statement of Work

Software Tool Services to Support Open Ontology Standard Development and Release

1 BACKGROUND INFORMATION

The National Institute of Standards and Technology (NIST) is conducting research in smart manufacturing systems integration with a focus on information standards for systems integration. One of the advancements in information standards for smart manufacturing is the use of formal ontologies.

Ontologies, in this context, are used to model semantics of data by means of logical expression. While many data standards used in industry today rely on natural language descriptions to convey data semantics, logical expression of data semantics allows for more precise data interpretation and processing by both machines and humans. With the availability of internet-based standards for exchanging ontologies, such as Web Ontology Language (OWL), and the increasing commercial support for storage and processing of large graph data, the manufacturing industry is increasingly interested in ontologies for describing its data. Such ontologies promise a new era of manufacturing information interoperability.

NIST is currently partnering with and participating in a standards consortium, the Industrial Ontology Foundry (IOF) [1], to develop a suite of ontologies for the manufacturing sector. Though guidelines, core ontology, and subdomain ontologies are being developed with NIST involvement, the process requires additional infrastructure to support and sustain the collaborative and distributed development and the publication of these modular ontologies. In support of the NIST mission to advance standards to enhance economic security, NIST seeks contractor support to develop and deliver an infrastructure to enable the deployment and quality of industrial ontologies developed by the IOF and NIST.

2 PURPOSE AND OBJECTIVES

The purpose of this procurement is to procure contractor services to recommend, modify, and/or develop software and documentation resources that will streamline the ontology publishing process. This work shall enable NIST in partnership with the IOF to robustly address US industry requirements for standard ontologies.

This ontology publishing process shall include encoding, sharing, revising, storing, commenting, controlling quality, and releasing ontologies. In conjunction with NIST, the contractor shall work with the IOF Technical Oversight Board (TOB), of which NIST is already a part, and at least one IOF working group to demonstrate that the new resources can streamline the publication of one or more new ontology modules as well as any changes to existing ontology modules needed to support the new module.

3 REQUIRED TASKS

The contractor shall provide all labor, project oversight, administration, and technical execution necessary to achieve the objectives and requirements outlined in this statement of work. The contractor shall be responsible for maintaining accurate records of project activities and shall perform the tasks and provide to NIST the deliverables described below.

3.1 Task 1: Define the ontology publishing process

The contractor shall work with the IOF Development and Release Management Working Group, TOB, and NIST IOF participants to develop a report that defines and documents an IOF development and publishing process. The definition of this process shall specify the roles, responsibilities, and activities associated with each step of a process that leads to the successful release of one or more related ontology modules. It is required of the release that industry be able to assess the suitability of the released ontology to their needs.

The activities of this process that the contractor shall perform include: ontology editing, revision, encoding, sharing, version control, commenting, quality control, and releasing.

Additional activities or finer grain activities may also be defined as detailed below.

3.2 Task 2: Develop software for supporting activities defined in Task 1

The contractor shall recommend software and, where there is an unmet need, enhance or develop software to support the process and activities defined in Task 1. Note: While IOF aims to publish ontologies in both OWL and Common Logic, the scope of this contract is only to enable the publication of OWL ontologies. The recommended and/or developed software shall:

i. Be compatible with Protégé desktop 5.5.0 [2] for editing OWL ontologies.

However, while Protégé is a critical editor to support, it has some behaviors that undermine the objectives of this contract, so the contractor shall recommend which editors be used in addition to Protégé to achieve the functionality specified in this task and shall demonstrate compatibility with these ontology editors.

ii. Serialize OWL in a normative RDF exchange form such that any differences in the files correspond only to actual changes made to the OWL.

Most ontology editors can encode OWL in several formats including the W3C normative RDF exchange formats (syntaxes): RDF/XML and Turtle. However, even these normative formats are not canonical. Therefore, an editor tool may change many aspects of how ontology entities are serialized every time the ontology is saved (such as adding/changing comments or changing the order and organization of statements) leading to difficulties in analyzing actual changes to OWL content.

To address this issue, the contractor shall provide a piece of software that works with the ontology editors recommended in Task 3.2.i and ensures consistent serialization in a W3C standard RDF exchange format between versions. This capability shall ensure that changes to class definitions and changes to property definitions can appear side-by-side between the same class and between the same property, respectively, using a recommended text comparison tool approved by NIST. This software shall support treating these exchange syntax files like program source code in collaborative code development environments/platforms like GitHub and must maintain naming and declarations consistent with conventions and rules determined by the IOF1. This capability must also ensure that the serialized form of released versions of IOF ontologies only differ where changes to OWL content were made.

iii. Include software for comparing versions of an ontology.

iv. Include software and approach for sharing and version control of the various ontologies. Currently, GitHub is used for sharing and version control. The contractor shall recommend whether to continue to use GitHub or otherwise recommend another similar software tool that interoperates with all other software tools recommended or developed to satisfy other tasks in this contract.

The rationale for the recommendation shall be provided. Along with GitHub or another alternative software tool, the contractor shall specify how the various ontologies (from different working groups) shall be stored by the tool, for example, in the same or different repositories. The contractor shall specify the directory structure of the recommended repository.

v. Include software and an associated approach for logging comments and issue resolution. The contractor shall recommend a software tool for logging comments (also known as issues, tickets, or bugs) and resolutions associated with definitions in an ontology. Currently, the intent is to use JIRA for this purpose.

However, the contractor shall either recommend continued use of JIRA or shall identify similar software that interoperates with all other software tools recommended or developed to satisfy other tasks in this contract. The rationale for the recommendation shall be provided. The contractor shall specify a taxonomy of labels for classifying comments logged against terms or sets of related terms in the recommended or developed tool. The classification shall distinguish the kind of comment and the disposition of work to resolve the problem described by the comment. The contractor shall provide definitions of the labels so defined.

vi. Include software and an associated methodology for ontology development project management. The contractor shall recommend a project management tool to use with ontology development and provide a rationale for the recommendation. The recommended tool shall be compatible with the recommended software tool in Task 3.2.v. Since software tools in Task 3.2.v and Task 3.2.vi need to be used together, an approach or software tool to use the two tools together shall be delivered. The project management functionality shall be able to group issues logged in Task 3.2.v according to a release milestone and to stage items according to project phases. Documentation of the approach/associated methodology shall also be provided. The approach shall define project stages and specify how they will be used to track progress towards each release of the ontology. The approach shall address tracking both the lifecycle of ontology development and how the lifecycles of ontology issues

1 These rules are evolving at that time of this writing. The awardee shall work with NIST and the IOF technical groups identified to refine these rules. The current state is available at the IOF Ontology Development Policies & Procedures pages[3] listed in the references.

interact with that development. The ontology development stages shall include typical data exchange standard publication lifecycle states such as draft, validated, candidate, balloted, and published. The contractor shall work with the IOF Release Management Task Group, of which NIST is a part, and NIST staff to define the process and document the workflow and the associated roles.

vii. Include software for assuring quality of an ontology. Aspects of ontology quality include a) semantic correctness, b) completeness of definitional elements, c) correctness of naming convention (e.g., IRI pattern), and d) correctness of declaration, e.g., required namespace, base IRI. The scope of quality assurance requirements for this contract includes (b) through (d). The contractor shall specify scripting language, scripts, and software used for executing the script language against an ontology or suite of ontologies that are stored in the software used in Task 3.2.iv. The contractor shall demonstrate that the scripting language can encode rules specified in the latest version of the following documents at the time of the end of contract including IOF Development Policies & Procedures [3], IRI Approach [4], and IOF Annotation Properties [5]. The tool shall be able to check a single ontology or the whole release.

viii. Include and demonstrate software to create documentation from ontologies developed using tools and approaches from this task that describe the ontology and its elements for domain experts.

ix. Include software and an approach for making and publishing a release of the IOF ontology suite. The software tool shall support the notion of Continuous Integration and Continuous Delivery (CI/CD) [6] that can automate the build (putting relevant files that are serialized canonically according to (ii) together), testing (as specified in (vii)), generating of documentation, making a release on the version control system specified in (iv), and publishing the release and its documentation to target systems (e.g., an IOF release web site). The contractor shall recommend or provide a software tool that enables automation of the aforementioned CI/CD process and demonstrates a release of multiple ontology modules. The tool shall interoperate with other tools in (i) to (vii) as necessary for the purpose of release automation. An example of such a software tool is Apache Jenkins. The contractor shall provide documentation for how to make a release in conjunction with other tools in (i) to (vii).

3.3 Task 3: Create User Guide, Set Up Guide, and Examples for Ontology Development Software

Contractor shall provide user guide documentation associated with the recommended software and contractor’s furnished software that supports the entire ontology development and release tasks described in (3.1). In addition, the contractor shall provide documentation and necessary materials such as example scripts and ontologies sufficient to set up and configure all software to demonstrate the whole process from ontologies editing to releasing outlined in (3.1).

3.4 Task 4: Evaluate the Mobi and Collaborative Protégé collaborative ontology development tools

Both Mobi and Collaborative Protégé are opensource collaborative ontology development tools. The contractor shall produce a report that includes evaluations of these tools in the context of Task 2. Specific questions to the contractor shall address include, but are not limited to:

• What role each of these tools can play in each of the subclauses of Task 2? What are the reasons (if any) that each tool is inappropriate for a certain role? These questions shall be answered from the perspective that there are no, or at most minor, enhancements to the latest version of either tool. In this context, minor enhancements means approximately a development effort that takes no more than 480 manhours (about 3 months) of a senior software engineer.

• How may it be integrated into the process? For example, since Mobi uses GitHub version management in the backend, can Mobi commit directly into the IOF version control system?

3.5 Task 5: Status/Progress Reporting and Meetings

The Contractor shall provide status/progress reports every two months that document the following for the previous 2 months: activities accomplished, deliverables completed, outstanding deliverables, any delays, reasons for delays, and recommendations that were brought to the attention of the TPOC. In the event of pressing concerns, the TPOC shall be notified in advance of the monthly status/progress report. Additionally, the Contractor shall participate in monthly virtual meetings during with status/progress reports and ongoing work efforts are discussed.

4 PERIOD OF PERFORMANCE

The period of performance shall be one (1) year from date of award.

5 PLACE OF PERFORMANCE

All work shall be performed at the Contractor’s facilities.

6 GOVERNMENT FURNISHED PROPERTY

No government furnished property will be provided as part of this contract.

7 DELIVERABLES

All deliverables under this requirement are subject to FAR Clause 52.227-17: Rights in Data – Special Works unless otherwise agreed in writing by NIST. Deliverables may be released by the Government under an open-source license.

Task Description Format Quantity Due Date (from date of award)

1 A digital document describing the ontology development and publication process.

MS Word 1 10 months

2 A digital document describing the OWL editing tools needed for

IOF

MS Word 1 2 months

2 Software for canonically serializing OWL in a normative rdf exchange format

Source code 1 3 months

2 Software for comparing OWL revisions

Source code 1 6 months

2 A digital document specifying software and approach for ontology sharing and version control, comment collection and resolution, and ontology lifecycle project management.

MS Word 1 8 months

2 Software for testing and assuring ontology quality

Source code, script files

1 3 months

2 Software for creating documentation from ontologies

Source code 1 7 months

2 Software that automates building, testing, documenting, and creating a release on a version control systems, and the publication of the release and its documentation

Source code and integration of software components

1 9 months

3 User and Set Up Guide and Examples

MS Word, text, rdf/xml files

4 11 months

4 A digital document evaluating collaborative ontology tools including Mobi and Collaborative Protégé

MS Word 1 6 months into the contract

5 Status reports MS Word 6 One every two months after the start of the contract

Standards for Acceptance of Deliverables: All deliverables shall be provided to the TPOC and shall be submitted via secure methods as directed by the TPOC. The TPOC will evaluate deliverables for completeness and accuracy and will either accept or reject them within 21 calendar days of contractor submission. Rejected deliverables shall be revised, updated, and resubmitted by the Contractor within 21 calendar days after receipts of TPOC feedback. The TPOC will provide written notification when a deliverable is accepted.

8 KEY PERSONNEL REQUIREMENTS

The Contractor is responsible for providing appropriate staff to support the contract requirements. As part of this, one Contractor Key Personnel is required as detailed below. The Contractor key personnel shall meet the minimum qualifications listed for the required key personnel position.

One (1) Knowledge Representation Specialist Minimum Education: Bachelor's degree from an accredited college or university in Arts, Engineering, Science, or other related field.

Minimum Experience: 15 years of experience in ontology development and application.

9 INFORMATION TECHNOLOGY DESIGNATION

The contractor shall have no access to NIST IT Systems.

10 PERSONALLY IDENTIFIABLE INFORMATION

This work does not contain Personally Identifiable Information (PII). A Privacy Impact Assessment is not applicable.

11 TRAVEL

No travel is required under this contract.

12 REFERENCES

1 Industrial Ontology Foundry – https://industrialontologies.org 2 Protégé ontology editing tool - https://protege.stanford.edu 3 IOF Ontology Development Policies & Procedures -https://oagiscore.atlassian.net/wiki/spaces/IOF/pages/3585802355/Ontology+De velopment+Policies+Procedures

4 IRI Approach -https://oagiscore.atlassian.net/wiki/spaces/IOF/pages/3564372109/IRI+Structure +and+Format

5 IOF Annotation Properties -https://github.com/iofoundry/Core/blob/main/meta/AnnotationVocabulary.rdf

6 CI/CD - https://en.wikipedia.org/wiki/CI/CD https://industrialontologies.org/ https://oagiscore.atlassian.net/wiki/spaces/IOF/pages/3585802355/Ontology+Development+Policies+Procedures https://oagiscore.atlassian.net/wiki/spaces/IOF/pages/3585802355/Ontology+Development+Policies+Procedures https://en.wikipedia.org/wiki/CI/CD