Hey! Yes, lazy string representation would be great! However, I am not sure to understand where you want to have them (sorry, I am missing some context on "heringerp project"). In Oxigraph oxiri::Iri is only used to validate IRIs and resolve relative ones. NamedNode (and NamedNodeRef) are the structs used in the APIs to represent RDF IRIs. The Store implementation providing SPARQL does not uses these types but rather an internal EncodingTerm struct that provides dictionary support and only builds the NamedNode object at the boundaries.

Moving a struct S to a trait T as significant cost on the codebase verbosity because either the trait needs to be wrapped into a dynamic pointer like (Box<dyn T>, Arc<dyn T> or &dyn T) or the concrete implementation of T to be used needs to be injected using generics (like struct Triple<ConcreteIriType>). It's why I have avoided to do it to keep the APIs a bit simpler. But I would be happy to change this decision if there are worth it use cases in the places where it can be useful.