I've previously blogged about the as(...) pattern I'm using for my projects. In an email exchange with Taylor Cowan, I've been made aware that Taylor has been using this pattern since a quite a few time in his JenaBean project (Jena is another big player in the world of RDF and Java). A stripped down pseudocode from his example:

object.as(DCTerms.class).title("thetitle").created("2006-09-07T09:33:30Z");

Have a look at his code since the examples are much more powerful than the excerpt above.

Second, another exchange with Tor Norbye (for a completely different topic) made me aware of an updated naming convention for Java identifiers containing acronyms. So, I'm now using SkosConcept and OwlThing in place of SKOSConcept and OWLThing.

Third, my friend Uberto Barbini suggested me that there's a way to get rid of that .class suffix, without hoping for a compiler change. If you define such a thing as:

public interface SkosConcept
  {
    public final static Class<SkosConcept> SkosConcept = SkosConcept.class;
   
    ...
  }

public interface GeoCoderEntityProxy
  {
    public final static Class<GeoCoderEntityProxy> GeoCoderEntityProxy = GeoCoderEntityProxy.class;
   
    ...
  }

you can write:

import static it.tidalwave.semantic.SkosConcept.SkosConcept;
import static it.tidalwave.geo.location.GeoCoderEntityProxy.GeoCoderEntityProxy;

List<GeoCoderEntityProxy> list = object.as(SkosConcept).findNarrowers().ofType(GeoCoderEntityProxy).results();

which is quite readable. The Java compiler is capable of understanding the difference between a type reference (for instance the GeoCoderEntityProxy generic parameter in List<>) and a field reference (such as the one statically imported). The only thing that you're loosing is that you won't be able to invoke an hypotethical static method such as GeoCoderEntityProxy.doSomething(). But in most cases I'm dealing with interfaces, so this is not a real issue.