On 08/01/15 13:50, Stian Soiland-Reyes wrote:
BTW.. why is there this confusing class hierarchy?
IRIFactory extends IRIFactoryImpl extends AbsIRIFactoryImpl implements
IRIFactoryI
I don't understand the question and probably don't know the answer anyway.
And it's not what I see.
abstract public class IRI
extends AbsIRIFactoryImpl
implements IRIFactoryI, IRIRelativize
public class IRIFactory
extends IRIFactoryImpl
implements IRIFactoryI
IRIs are "self factories" - given one, you can make another with
"construct" and "create" (IRI resolution occurs).
The final "I" in IRIFactoryI is "Interface" -- an old style naming.
Andy
On 8 January 2015 at 13:30, Andy Seaborne <a...@apache.org> wrote:
On 08/01/15 12:57, Martynas Jusevičius wrote:
Thanks.
Couldn't Jena's IRI be made to extend java.net.URI, override the
methods that differ, and still be accepted where URI is expected?
java.net.URI is a final class.
Probably other issues as well (IRIs are unicode, URIs are ASCII ; RFC 2396
vs 3896) but that's a blocker in itself.
IRIs are not particularly cheap - the resolver has caching to mitigate this.
The parsing rules such as the scheme-specific stuff (that IRI adds over
j.n.URI) can have a noticeable cost (e.g. parsing). Another cost is the use
of regexs - using java.net.URI to parse the structure (it has a hand-written
URI parser) might help partly.
Slightly bizarrely, if you pass in the components of a java.net.URI, java
builds a string and parses it to get the components again.
Adding IRI.toURI operation might help c.f. IRI.toURL. Contributions
welcome.
Andy
On Tue, Jan 6, 2015 at 10:27 PM, Andy Seaborne <a...@apache.org> wrote:
On 06/01/15 16:22, Martynas Jusevičius wrote:
Hey,
I'm reading URIs from request input that will end up in an RDF Model.
They can be relative, in which case they need to be resolved, and they
can be invalid, in which case they need to be rejected.
What I'm looking for is to replace new URI/URI.create() and
URI.resolve(uri) usages with a more RDF-compliant solution.
I wanted to check if IRIResolver is the right class for this purpose?
Are there any examples?
org.apache.jena.riot.system.IRIResolver (not the legacy one in the old N3
parser).
This uses the jena-iri library which is quite, err, "precise".
See also the parsing pipeline that uses CheckerIRI for checking. In
fact,
you might want to use StreamRDF (where all parers send things).
Andy
Thanks.
Martynas
