OWLAPI-v6 domain namespace.

[sszuev]

Is it possible to change (or at least to discuss the possibility of changing) the domain name for v6 api? The current package name is org.semanticweb.owlapi6.model.

I may be wrong (sorry if so), but it seems to me that the numbers in the domain (regardless of the subject specifics) is just a sign of poor style, i.e. some hint at some kind of internal knowledge, closed to most of people. Such style may lead to some misunderstanding. There are OWL1 and OWL2 specifications, and owlapi6 in the package names may confuse users, they may think that this is about OWL6.

There is no maven-release for v6, so I hope it is not too late to change the domain name. Maybe, the domain com.github.owlcs.owlapi would do ?

---

Why might this be important? The context is the following: Protege and Webprotege are stuck on owlapi v4, as far as I know. I see the reasons of such decision for Protege (plugins compatibility), although I can't see any reasons of that sort for Webprotege (it could be some kind of personal preference - again, sorry if I'm wrong), it uses v4 anyway. In view of this, the story with v4-adapters and v6 sounds good. Otherwise, we would have to do a lot of work to switch v4 -> v5, but finally get almost useless thing (I have such example: RDF-Protege).

[ignazio1977]

Adding numbers to package names is controversial, there are arguments both ways.

For OWLAPI, the intention was to allow multiple OWLAPI versions on the classpath without clashes. Conflicting versions are a common issue in my experience - many questions by users confused about the errors they're getting when using libraries using different versions. Also one of the reasons protégé is stuck - no easy way of supporting plugins requiring different versions. OSGi would allow this separation, if used properly, but this is quite complex to achieve and maintain, both for me and for other developers - many of the questions I've seen are from developers who are new to java or for whom developing in java is not the main job.

Some Apache libraries have done the same to avoid conflicts, e.g., commons collections and other utilities.

Having separate packages would allow the adapters you mention to be implemented. Using a number or a different package name doesn't make a difference here, so using a github domain instead of the current one would work. However, how would we change this for version 7?

I'd argue that not having the version number in the package is worse, when wanting to support multiple versions side by side. The developers would need to remember which version is the one they're after, and would need to know the convention used (e.g., Ubuntu using codenames that progress alphabetically for successive versions gives a good clue as to what version is newest).

All of these approaches complicate cherry picking bug fixes and file history - I don't see a solution to both problems.

I'm not worried about people thinking OWLAPI 6 is for OWL 6, though.

[sszuev]

1) a solution acceptable for apache-commons may not be acceptable for other libs 2) in the java world, the case of domains without numbers is much more common, even after rebranding 3) focusing on beginners-support may lead to poor design 4) there is no need for v7 yet; as for me, the need for v5/v6 still raises questions 5) RDF-support by means of ontapi still exists only for v5

---

I think the key-word here is 'some': the commons-collection library is a pretty rare exclusion from the common rule. And that library is a set of utilities, without a single strict specification, it is about a large amount of heterogeneous functionality. Also it is about a huge number of customers. I'm not sure the comparison is really appropriate here. I can image when the project requires commons-math-v1 and commons-math-v3 together, but cannot when it nees owlapi-v3 and owlapi-v6 - the last use case looks more like a mistake or some untidiness, unacceptable for serious project.

There are a lot of other examples when a domain was changed without numbering. Many projects have gone through such a rebranding, and finally they got good domains, without those frustrating digits. (log4j did that, junit, jackson, eigenbase, poi, even from our spec: apache jena). It seems to be a common thing in opensource evolution.

I think, most opensource maintainers don't really care about those who don't even know which version of the library they have in their own classpath, and, in general, what a classpass is. Proper naming usually is much more important thing then supporting newbies. Here, on OWLAPI project, everything is quite the opposite: a good supports of students doing their one-time homework, but questionable design. (and in the same time you don't worry about people thinking OWLAPI 6 is for OWL 6? hm)

Also, honestly, I still don't see any good reason for appearing v5 (stream-api? is it all?). All of these branches - v4, v5, v6 - are basically about the only one thing - about OWL2. And functionality is almost the same. The architecture and the general approach are also the same. The differences are only cosmetic. So the hypothetical future v7 already seems to me even more redundant (sorry). As for v6-adapters - it is looks like a correction of mistakes, when we take a step back to v4 realizing that nobody following us with our v5.

And now, I think, it is possible to do everything more deliberately, with new namespaces, taking into account that RDF-support may also be available (which could be a worthwhile feature), but also taking into account that some other people will definitely not switch their community-important projects to use OWLAPIv5.

Well, it would be strange to expect the author to change his mind =). At least I had to try: when the maven release comes out, it will be too late. And now, at least, there is a different opinion and one vote against.

[ignazio1977]

I can image when the project requires commons-math-v1 and commons-math-v3 together, but cannot when it nees owlapi-v3 and owlapi-v6 - the last use case looks more like a mistake or some untidiness, unacceptable for serious project

Protege and any project that uses third party libraries run that risk - have actually met that obstacle, I should say.

That version 7 is not planned does not mean it would be a good choice to keep a design that doesn't allow for interface evolution.

Let's put aside questions of whether major versions changes should have happened. The issue list has interesting arguments about this, going the other way: according to tools checking binary compatibility, we should be on version 10 already (due to a number of changes, bug fix included). There are other reasons for projects to not have updated, which is not up to me to disclose - but, about that, it's enough to say that many popular projects are on old versions of OWLAPI 4. They're not updating to the latest minor release for reasons other than interface changes.

Matter of fact is, version 5 has existed for years, so we have do deal with that.

Main issue that the change of package names is meant to address: multiple versions coexisting, which also means reasoners for V4 being able to work with other versions (OWLReasoner being the main interface in question).

Changing to a package name without numbers is a possibility. I'm not happy about changing package names at all, number or no number, just want to avoid perpetuating mistakes.

[ignazio1977]

There's no release date for version 6, no need to rush decisions over the holiday season.

[ignazio1977]

org.semanticweb.owlapi6.model rolled back to org.semanticweb.owlapi.model

Branch history rewritten to remove the rename - this avoids troubles reading the history to figure out which files were modified. Previous version6 branch preserved as version6_abandoned.