Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[rdf4j-dev] Java naming conventions for IRI vocabulary constants


Hi folks,

I'm currently working on a refactor of the vocabulary used for specifying config files for repositories - see https://github.com/eclipse/rdf4j/issues/4401 . Main motivation is to get rid of the old "http://openrdf.org/" domain name. I'm aiming to replace with it with a tag URI namespace instead (tag:rdf4j.org,2023:config/) and am also looking at cleaning up the terminology itself (and settle on a single config namespace instead of a separate one for each component). Anyway that's all up for discussion on the (draft) PR.

However, I wanted to get some opinions on how we more generally represent the constants for RDF vocabularies in Java, in particular, the naming conventions we use.

Most of our vocabularies have been following these conventions:
  1. the class name is the prefix of the vocabulary, in all caps. Examples: org.eclipse.rdf4j.model.vocabulary.RDF, GEO, FOAF, etc. This is actually a bit of break with common Java conventions, which typically say to use mixed case for abbreviations longer than two letters.
  2. each vocabulary term is an IRI constant, and follows the standard Eclipse/Oracle naming conventions for constants in Java: ALL_CAPS. We give the term the actual resource name, so that the combination of class and term resembles that prefix:term notation of RDF itself. Examples: rdf:type becomes RDF.TYPE, and time:DateTimeInterval becomes TIME.DATE_TIME_INTERVAL.
However, we have not always been very consistent with this convention.
  • We don't consistently use underscores to separate multi-word terms: for example, the constants for rdfs:subClassOf  and rdfs:ContainerMembershipProperty are RDFS.SUBCLASSOF  and RDFS.CONTAINERMEMBERSHIPPROPERTY (it should be RDFS.SUB_CLASS_OF and RDFS.CONTAINER_MEMBERSHIP_PROPERTY).
  • in some vocabularies we have the problem of the same term in different capitalization meaning different things, e.g. in the SPIN vocabulary we have spin:Column (the class) and spin:column (the property). We have worked around that rather clunkily by adding a suffix: SPIN.COLUMN_CLASS and SPIN.COLUMN_PROPERTY.
  • For the configuration vocabularies for the various components (repositories and sails), we have often used completely different class names: RepositoryConfigSchema, for example.
None of this is the end of the world, we are at least _somewhat_ consistent and I'm not suggesting that we completely refactor all our existing vocabulary immediately. However, with my refactor of the config vocabulary in the back of my mind, I was wondering if we should think about updating our conventions. We can decide on what convention we'd ideally want and then adopt that for new things, gradually moving existing vocabularies over (in a backward-compatible manner).

One possible change we could do (which I think Haved has already been using for some SHACL-related vocabulary constants), is to break with the Java convention of using ALL_CAPS for these constants, and instead use mixed case to represent them. So, instead of RDFS.SUBCLASSOF, we'd have RDFS.subClassOf, and we'd be able to have SPIN.Column and SPIN.column.

Another possible change we could do is change the class names for vocabularies to mixed case. So we'd get Rdfs.subClassOf, Xsd.dateTime, and Spin.Column.

Thoughts?

Jeen





Back to the top