Thea2 suggested fix - writing ontology/1 at top of plsyn file

The thea2 library owl2_plsyn.pl writes the ontology/1 declaration at the bottom of a saved .plsyn file, but actually requires it at the top when exporting the file to .ttl format. For example, if you have the following plsyn file:

fu < bar.
ontology(mini).

and try to export it with save_axioms('mini.ttl',ttl). then the exported mini.ttl file will not contain anything other than the ontology declaration (i.e. the fu<bar subClass declaration will be missing).

A possible solution is to ensure (manually) that any ontology/1 declaration is written first. However, this is a problem when going through a cycle of importing from, say, .ttl then saving in .plsyn and then exporting back to .ttl again (presumably after making changes in the plsyn file). The reason is that you would have to remember to move that declaration to the top of the file during editing, because otherwise the export to .ttl won’t work.

A programmatic fix for this, is to modify the owl2_plsyn.pl code so that the ontology/1 declaration is always written at the top of a .plsyn file. The following modification to the write_owl_as_plsyn/1 predicate in that library will accomplish this. I essentially made two changes: firstly, to retrieve the ontology declaration and write it first. Secondly, to prevent any ontology declaration from being written in the main axiom writing forall predicate.

The only slight complication is in the first clause of write_owl_as_plsyn/1. This clause deals with the possibility that multiple ontologies have been loaded – i.e. there are multiple ontology/1 clauses. The clause also looks at the contents of the Opts parameter to see if any ontologies need to be filtered out. I expediently choose the first ontology clause as the name for the new saved ontology. This is a crude choice, but saves having to invent an ontology name. In future, it’s probably better to construct a new ontology name from the file name that is being saved into, but then we still need to decide where to get the URI prefix from.

write_owl_as_plsyn(Opts):-
	setof(Ont,member(ontology(Ont),Opts),Onts),
	!,
	Onts=[FirstOnt|_],		% ensure ontology/1 is written at top...
	writeln(ontology(FirstOnt)),	% use first ontology as new ontology name
	% this clause optimized for ontology filtering
        forall((member(Ont,Onts),
		ontologyAxiom(Ont,A),
		A\=ontology(_),
		\+exclude_axiom(A,Opts)),
	       (   plsyn_owl(Pl,A,Opts),
		   format('~q.~n',[Pl]))).

write_owl_as_plsyn(Opts):-
	% ensure to write ontology/1 at the top, if it exists
	( axiom(ontology(Ont)) -> writeln(ontology(Ont)); true	),
        forall((axiom(A),
		A\=ontology(_),
		\+exclude_axiom(A,Opts)),
	       (   plsyn_owl(Pl,A,Opts),
		   format('~q.~n',[Pl]))).

2 Likes

Good to see interest in thea2 and fixing issues! Integrated. Replaced writeln/1 by `format(’~q.~n’, …) to guarantee proper quoting and a full-stop.

If you have more, could you use github pull requests? That makes changes tracktable and simplifies integration a lot (with less risk on mistakes).

Thanks, Jan – happy to use pull requests. But I’ll admit I’m a bit hazy on the proper (preferred) git process. Do I raise an issue first, and then create a separate branch (will need write access for that), and ultimately a pull request? (and are there naming conventions to be observed?)

I am no GitHub Jedi (I just coined that) but if the change is simple and a single file you need to find the file you need to change at GitHub SWI-Prolog site, e.g.

click the pencil icon for editing, you should be able to edit the file and then at the bottom add a reason for the edit and click Purpose file change I think that will do it. That is how I did this change.

See:
Editing files in your repository
Editing files in another user’s repository

HTH

4 Likes

Nice that there is a really simple route for small stuff. Notably handy for small documentation issues! The normal one, assuming you do your work on the sources obtained using git clone from github:

git  checkout -b fix-for-xyz
<fix/extend/clean the code>
<commit using your favorite tool>
    (repeat the two above as long as needed, preferably do not put
     unrelated stuff in one commit)
git push origin fix-for-xyz

And github will reply with a link for creating the PR. If the PR is accepted and processed (with or without changes, do

git checkout master
git pull
git branch -D fix-for-xyz
4 Likes

Thanks, Jan – this reply is a wonderful succinct procedure that is worthy to go into some SWI-Prolog general guidance somewhere :slight_smile:

Wiki: GitHub Pull Request

2 Likes

Great! I’ve also added Jan’s guidance to the SWI-Prolog Wiki, on the package how-to page (which has a section on how to use github): https://eu.swi-prolog.org/howto/Pack.txt

1 Like