Implement support for inlining URIs based on data types. The test case is a family of URIs have a common prefix and a trailing UUID. The prefix will be represented by a Vocabulary IV and will be followed by the UUID. The UUID will be represented as an inline UUID (DTE.UUID).
Per below, this may break the existing IPv4 support in which case that will need to be reimplemented.
Mike wrote: I don't think this will be that easy. We don't have a great mechanism for inlining things outside the DTE space, which you'd need to do regardless of whether you're trying to inline a URI or a Literal. We had this DTE.Extension placeholder that I believe was meant to allow for a larger range of DTE values (according to its javadoc), but we never put in place the mechanism for this to actually work. In fact I hijacked DTE.Extension for IPv4 because of this limitation - I needed a new DTE and had no means of registering one. Note that DTE.Extension is separate from the extension bit in the flags. I've also tried using that extension mechanism to inline new kinds of data, but again there you are still thwarted by the limited DTE value space and the lack of ability to extend it. We are also unable to do compound inlines (UUID+something else) for the same reason, because again, there is no DTE space available for compound values. I wanted to do a compound DTE for IPv4 + Port but was unable.
You'd need to create a DTE extension factory and use an additional byte (or two) after the flags that described the extended DTE value for new or compound data types.
Or you could just totally hack it by finding a way to encode their data into a BigInteger and then using DTE.XSDInteger.