Make versioning and operators ontology accessible over HTTP

[rjyounes]

Needed to support gist imports of these ontologies. See #979.

[Jamie-SA]

Now available:

https://w3id.org/semanticarts/ontology/operators1.0.0
https://w3id.org/semanticarts/ontology/versioning1.0.0

[pmcb55]

Just a nitpick, but I notice the value of the ver:hasVersionNumber triple in this ontology is a Blank Node:

<https://w3id.org/semanticarts/ontology/versioning> a owl:Ontology ;
	ver:hasVersionNumber [
		a ver:SemanticVersionNumber ;
		ver:uniqueText "1.0.0"^^xsd:string ;
	] ;

...whereas I tend to favour avoiding BNodes wherever possible, and indeed gist itself uses a Named Individual for it's sh:PrefixDeclaration, i.e.,:

<https://w3id.org/semanticarts/ontology/gistCore> a owl:Ontology;
    sh:declare gist:_PrefixDeclaration_gist.
    
gist:_PrefixDeclaration_gist a sh:PrefixDeclaration;
    sh:namespace "https://w3id.org/semanticarts/ns/ontology/gist/"^^xsd:anyURI;
    sh:prefix "gist".

So in other words, to be consistent, should this ontology do likewise, i.e.,:

<https://w3id.org/semanticarts/ontology/versioning> a owl:Ontology ;
  ver:hasVersionNumber ver:_SemanticVersionNumber_versioning .

ver:_SemanticVersionNumber_versioning a ver:SemanticVersionNumber ;
  ver:uniqueText "1.0.0"^^xsd:string .

...?

[uscholdm]

Just a nitpick, but I notice the value of the ver:hasVersionNumber triple in this ontology is a Blank Node:
ver:_SemanticVersionNumber_versioning a ver:SemanticVersionNumber ;
ver:uniqueText "1.0.0"^^xsd:string .

That is a personal choice. It can work either way - implementer's choice. There is the slight overhead of thinking up and creating IRIs for each version number. It would require a way to distinguish different version numbers, so the example above would not be ideal.

[pmcb55]

Ah, yes, of course! I hadn't actually realized that each new version would indeed require a newly minted NamedIndividual!

And yeah sure, you can leave it as a personal choice if you like - it's just that I much offering prescriptive guidelines - i.e., telling people you prefer one specific convention, and that you use it consistently everywhere yourself (i.e., leading by example), instead of leaving it up to them to have to make decisions for themselves (just 'cos most people prefer not to have to make decisions, especially on stuff (like this particular question, most likely!) that they just don't care about).

But it seems your publishing process is already treating the 'source' Turtle file (here) as a template with placeholders for the 'current' version number, i.e., the use of "X.x.x" in two triples here:

<https://w3id.org/semanticarts/ontology/versioning>
	a owl:Ontology ;
	owl:imports <https://w3id.org/semanticarts/ontology/operators1.0.0> ;
	owl:versionIRI <https://w3id.org/semanticarts/ontology/versioningX.x.x> ;
	skos:definition "Generic concepts for semantic versioning of a suite of artifacts for semantic systems in production."^^xsd:string ;
	skos:editorialNote "Although this was originally intended for semantic version numbers, the ontology could be tweaked in a very small way to use different version numbers, so long as they are ordered."^^xsd:string ;
	skos:example "The semantic version number for the disease taxonomy is 6.3.0. This version depends on the version of the imported disease ontology being at least 3.1.0 and less than 4.0.0. It also depends on the version of gist core being at least 12.1.0 and less than 13.0.0."^^xsd:string ;
	skos:prefLabel "Semantic Versioning Ontology"^^xsd:string ;
	ver:hasVersionNumber [
		a ver:SemanticVersionNumber ;
		ver:uniqueText "X.x.x"^^xsd:string ;
	] ;
	.

So given that you're doing this search-and-replace in two places already for this ontology, I think I'd opt to do it a third time just to get rid of that pesky Blank Node, i.e., update the 'template Turtle' to be:

<https://w3id.org/semanticarts/ontology/versioning>
	a owl:Ontology ;
	owl:imports <https://w3id.org/semanticarts/ontology/operators1.0.0> ;
	owl:versionIRI <https://w3id.org/semanticarts/ontology/versioningX.x.x> ;
	skos:definition "Generic concepts for semantic versioning of a suite of artifacts for semantic systems in production."^^xsd:string ;
	skos:editorialNote "Although this was originally intended for semantic version numbers, the ontology could be tweaked in a very small way to use different version numbers, so long as they are ordered."^^xsd:string ;
	skos:example "The semantic version number for the disease taxonomy is 6.3.0. This version depends on the version of the imported disease ontology being at least 3.1.0 and less than 4.0.0. It also depends on the version of gist core being at least 12.1.0 and less than 13.0.0."^^xsd:string ;
	skos:prefLabel "Semantic Versioning Ontology"^^xsd:string ;
	ver:hasVersionNumber ver:_SemanticVersionNumber_versioningX.x.x ;
        .

ver:_SemanticVersionNumber_versioningX.x.x a ver:SemanticVersionNumber ;
  ver:uniqueText "X.x.x"^^xsd:string .

But yeah, it's not a biggie - I just saw an opportunity to squish a BNode and couldn't resist :) !

[rjyounes]

We use anonymous classes throughout the ontology for restrictions, unions, and intersections. I would find it bothersome to create named classes for each of these.

[uscholdm]

I just saw an opportunity to squish a BNode and couldn't resist

I think it's mostly a matter of personal taste, rather than good practice.

[pmcb55]

We use anonymous classes throughout the ontology...

Oh yeah @rjyounes, I wouldn't propose trying to squish all the BNodes, as I wouldn't think it's feasible when using OWL extensively (at least not while maintaining a high degree of readability). I was really just referring to squishing this one non-OWL-related BNode in the metadata of the ontology itself, that's all.

I think it's mostly a matter of personal taste...

Yep, for sure, it is @uscholdm - no argument there. But my point was simply that, personally, I'd still stipulate a 'gist community' preference/Best Practice for all these kinds of things. My reason is literally just to try and maintain a degree of consistency, because inconsistency (i.e., leaving it to 'personal taste') just causes confusion and angst for newbies (as they wonder which one is 'better', or which one they 'should use' themselves for their ontologies when they inevitably come across all the different personal tastes).

For me, it's the very reason that Prettier took off so massively in the JavaScript world - i.e., most people really don't care, and they don't want to have to 'make decisions', or to decide on what their 'personal taste' is. Instead, they'd just prefer someone or something that's explicitly 'opinionated' to tell them what to do (or even better, to do it for them - i.e., prettier --write) 😄 !).

(And yes, I would be very interested in seeing someone develop a Prettier plug-in for Turtle - maybe Inrupt, if only we could find the time...)