Artifacts

Artifacts are deliverables, single files that are produced by a build process by an automated “continuous integration” (CI) platform like Jenkins, from the original git-based authoritative sources.

The artifacts, and NOT the sources themselves, are the “things” that need to be tested and evaluated on a continuous basis. FIBO end users will only be exposed to the artifacts so that’s what we need to test, not the sources.

Building the artifacts and storing them on https://spec.edmcouncil.org, thereby making them visible publically, is also called “publishing”.

So the artifact builder is also called “the publisher” where for each “flavor” of FIBO we might have different programs that take care of the specifics of generating the flavor-specific artifacts.

Since every approved change, coming in via a “code-reviewed” and accepted pull-request into the main FIBO repository, needs to be tested by automated processes and needs to be evaluated by humans, we need to publish each and every change and generate all artifacts with their own version number or branch color. Actually, the publisher process itself is one of those tests, a major one even. If it gets through the publisher without any warnings or errors, your change was probably valid.

Types of Artifacts

Serialization Formats

For the ontology and vocabulary flavors of FIBO, the primary publishing format is RDF. Even the OWL files are usually stored as RDF (although not all OWL formats are actually RDF).

The main RDF serialization formats are:

The main OWL serialization formats are:

We’re “probably” not going to support ALL of these formats but only the most popular ones. It shouldn’t really matter though to add a few more, whenever there’s a customer with a preference for a given format.