Jena Rule Failure

21 views
Skip to first unread message

donundeen

unread,
Jul 22, 2008, 4:01:09 PM7/22/08
to TopBraid Composer Users
I'm setting up some jena rules in my ontology, and was initially
having lots of success, when something broke, which i can't now fix.

Background: I've got a sesame repository, represented by a file,
sesame.s2r in my project. I've got a "main" owl file, "main.owl",
which imports that s2r file.

I'm using these jena rules to map one ontology (import from d2r) to
another (standards-based ontology).

Initially, I created a jena:rule in main.owl, by creating a jena:rule
property as a property of the class definition for one of the classes
in my target ontology. The rule looks like this:

[CreateIdentifier2:
(?obj http://metmuseum.org/rdf/vocab/#Objects_ObjectNumber ?
objNumber),
uriConcat(<http://metmuseum.org/rdf/derived/E42ObjectIdentifier#>, ?
objNumber, ?objIdentifier)
->
(?obj <file:/C:/Documents%20and%20Settings/undeed/TBC-ME-workspace/
MulgaraConnect/cidoc_v4.2.rdfs#P47F.is_identified_by> ?objIdentifier),
(?objIdentifier <http://purl.org/dc/elements/1.1/title> ?objNumber)]


When I run the inferencer, I get the error (from the tomcat logfile,
or the console when I run TBC with the -console option):

Jul 22, 2008 3:46:18 PM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet openrdf-http-server threw
exception
java.net.URISyntaxException: Illegal character in fragment at index
60: http://metmuseum.org/rdf/derived/E42ObjectIdentifier#09.12.3
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.checkChars(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.<init>(Unknown Source)
at org.mulgara.util.URIHelper.createNetURI(URIHelper.java:138)
at org.mulgara.util.URIHelper.toURI(URIHelper.java:125)
at org.mulgara.util.URIHelper.getScheme(URIHelper.java:90)
at
org.mulgara.resolver.StringPoolSession.mapRelative(StringPoolSession.java:
618)
at
org.mulgara.resolver.StringPoolSession.localizeSPObject(StringPoolSession.java:
515)
at
org.mulgara.resolver.StringPoolSession.localize(StringPoolSession.java:
427)
at
org.mulgara.resolver.StringPoolSession.localize(StringPoolSession.java:
206)
at
org.mulgara.resolver.store.StatementStoreResolver.localize(StatementStoreResolver.java:
460)
at
org.mulgara.resolver.LocalQueryResolver.localize(LocalQueryResolver.java:
147)
at org.mulgara.resolver.DefaultConstraintHandlers
$28.localize(DefaultConstraintHandlers.java:379)
at
org.mulgara.resolver.ConstraintOperations.localize(ConstraintOperations.java:
240)
at
org.mulgara.resolver.LocalQueryResolver.resolve(LocalQueryResolver.java:
196)
at org.mulgara.resolver.DefaultConstraintHandlers
$10.resolve(DefaultConstraintHandlers.java:241)
at
org.mulgara.resolver.ConstraintOperations.resolveConstraintExpression(ConstraintOperations.java:
187)
at
org.mulgara.resolver.LocalQueryResolver.resolveConstraintOperation(LocalQueryResolver.java:
129)
at org.mulgara.resolver.DefaultConstraintHandlers
$5.resolve(DefaultConstraintHandlers.java:170)
at
org.mulgara.resolver.ConstraintOperations.resolveConstraintExpression(ConstraintOperations.java:
187)
at
org.mulgara.resolver.LocalQueryResolver.resolveE(LocalQueryResolver.java:
285)
at
org.mulgara.resolver.DatabaseOperationContext.doQuery(DatabaseOperationContext.java:
809)
at org.mulgara.resolver.QueryOperation.execute(QueryOperation.java:
138)
at
org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:
569)
at org.mulgara.resolver.DatabaseSession.execute(DatabaseSession.java:
639)
at org.mulgara.resolver.DatabaseSession.query(DatabaseSession.java:
402)
at
org.openrdf.sail.mulgara.MulgaraConnection.getStatements(MulgaraConnection.java:
243)
at
org.openrdf.sail.mulgara.MulgaraConnection.getStatements(MulgaraConnection.java:
57)
at
org.openrdf.repository.sail.SailRepositoryConnection.getStatements(SailRepositoryConnection.java:
177)
at
org.openrdf.repository.sail.SailRepositoryConnection.exportStatements(SailRepositoryConnection.java:
204)
at
org.openrdf.http.server.repository.statements.ExportStatementsView.render(ExportStatementsView.java:
99)
at
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:
1160)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:
901)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:
809)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:
476)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:
431)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
844)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
447)
at java.lang.Thread.run(Unknown Source)



I've tried other ways of expressing that uriConcat line, like

uriConcat('http://metmuseum.org/rdf/derived/E42ObjectIdentifier#', ?
objNumber, ?objIdentifier)
or
uriConcat(vocab:E42ObjectIdentifier, ?objNumber, ?objIdentifier)
(where vocab is a defined prefix)

all to more or less the same effect.

can anyone see what the problem is with my rule?

The thing, it worked at least once. which is why it's so frustrating
now.

donundeen

unread,
Jul 23, 2008, 2:07:37 PM7/23/08
to TopBraid Composer Users
Also, I see these errors only by running TBC with the -console option.
Otherwise, I just see the inference execution end (even with a java
OutOfMemoryException finally ending the process), with nothing shown
on the main interface, other than there being no triple infered.

If this is a matter of my syntax being wrong, then TBC could be
checking that, and making the entry box red, like it does with other
syntax issues.

My other thought is that the generated triple has a bad syntax, ie
http://metmuseum.org/rdf/derived/E42ObjectIdentifier#09.12.3
is somehow formatted badly.

After reviewing several of these errors, the "fragment index" of the
error is directly proportional to the length of the generated uri.
so the "index" refers to the end of the uri, but I dont' know if that
means the error is the last character in the uri, or that the
"fragment" that contains the error ends at the end of the uri?

anyways, is there a jena function for making string uri-safe?

Scott Henninger

unread,
Jul 23, 2008, 2:42:45 PM7/23/08
to TopBraid Composer Users
Don; You could try tops:hasURI in Help > TopBraid Composer > Reference
> SPARQL Property Functions
or
smf:buidURI in Help > TopBraid Composer > Reference >TopBraid
SPARQLMotion Functions Library

-- Scott

On Jul 23, 1:07 pm, donundeen <donund...@gmail.com> wrote:
> Also, I see these errors only by running TBC with the -console option.
> Otherwise, I just see the inference execution end (even with a java
> OutOfMemoryException finally ending the process), with nothing shown
> on the main interface, other than there being no triple infered.
>
> If this is a matter of my syntax being wrong, then TBC could be
> checking that, and making the entry box red, like it does with other
> syntax issues.
>
> My other thought is that the generated triple has a bad syntax, iehttp://metmuseum.org/rdf/derived/E42ObjectIdentifier#09.12.3

Scott Henninger

unread,
Jul 23, 2008, 3:08:39 PM7/23/08
to TopBraid Composer Users
Sorry about that Don. I answered that as a SPARQL question, but you
are clear that this is a Jena rule. TBC uses a Jena rules parser to
check rule input. If the problem is not found there (rule syntax -
the red box around the rule text), then it comes down to problems in
the Jena engine. In terms of the question on whether a URI-safe Jena
function, that question would be better answered by a Jena user
group. In general, SPARQL might be a better and more portable
solution.

-- Scott

On Jul 23, 1:42 pm, Scott Henninger <shennin...@topquadrant.com>
wrote:

donundeen

unread,
Jul 23, 2008, 4:39:40 PM7/23/08
to TopBraid Composer Users
Hm, my original impression was that since what I wanted to do was
really apply rules to generate a new ontology from the exisitng one, I
thought I should use rules, like swrl or jena (swrl doesn't seem to
have the string manipulation I need), so I could make this a part of
the inference step. But I see now that there's an option in inference
configuration to make SPARQL constructs a part of the inference. And
when I think about it, a jena rule is pretty much exactly like a
SPARQL Construct, just in reverse. And really, I don't like either of
them. I don't like that I'm working in a paradigm that revolves around
little pieces of granular information (triples), yet my main
manipulation of those triples is with big ugly strings (Construct
statements) stored as property values. It just feels wrong, but I
guess that's a topic for another day.

I think i'll switch my approach to SPARQL. Do you think the
performance will suffer?

On Jul 23, 3:08 pm, Scott Henninger <shennin...@topquadrant.com>

Holger Knublauch

unread,
Jul 23, 2008, 5:28:31 PM7/23/08
to topbraid-co...@googlegroups.com
Hi Don,

whenever the mapping rules between source and target models lead to no
cycles, then SPARQL or Jena rules will have the same power. Rules are
currently only more efficient if you have to chain them together, i.e.
the inferences created by one rule would impact the outcome of another
rule. For mapping problems in general, SPARQL is a better solution
IMHO, because it's a standard. Tool support for SPARQL is also much
better, especially in TopBraid. We will be publishing visual SPARQL
editors in the future as well.

Under the constraints above, performance is likely to be even faster
than Jena rules because the system would be able to use native
database SPARQL queries (all major RDF databases have native SPARQL
engines).

Holger

Reply all
Reply to author
Forward
0 new messages