Scott and Jeremy,
Thank you for the explanations. With the information provided I have
been able to update my scripts successfully. I’ll share some
experiences garnered from the refactoring process that could benefit a
future release of TBC, and will ask a few more questions along the
way.
* Installing the Windows 64bit version of TBC-ME-3.4 on a 64bit
version of Windows 7 I was a little surprised when the installer
wanted to put the program under C:\Program Files (x86)\ (where 32bit
applications reside) vs C:\Program Files. I recollect the Beta
installers did the right thing. So I was left wondering if the
application was truly 64bit –I double checked that I had downloaded
the right file.
* With the kennedys.rdf ontology in the foreground, running the
following query:
SELECT ?g { GRAPH ?g { ?s kennedys:child ?o . } }
Gives the initial exception:
java.lang.IllegalArgumentException: Missing Calais license key - see
Calais Preferences (under Window > Preferences... > TopBraid Composer)
at org.topbraid.calais.CalaisUtil.callCalais(CalaisUtil.java:39)
at
org.topbraid.calais.graphstore.CalaisGraphStore.load(CalaisGraphStore.java:
63)
Which was unexpected –why is the SPARQL engine, or TBC, trying to
connect to Calais?? I wasn’t expecting to query the entire
universe!? <MontyPythonReference>[Enter stage left] TBL, Eric & Andy:
"No one ever expects to query the entire universe!"</
MontyPythonReference>
Obtaining a Calais key, the query succeeds. However, I would have
preferred that this exception be caught and silently ignored. I also
do not want to incur the overhead of Calais transactions and possibly
obtain unexpected results from them. Are they really happening? Is
DBPedia, and other supported services, also being queried behind the
scenes? I really only expected the foreground ontology and its import
tree to be the triple set of the query. An option to effect this
would help.
* The query template that appears in a PerformUpdate module’s
sml:updateQuery does not contain a GRAPH modifier –understandable
since it cannot be predicted where one is needed. However, a query
can be filled out without an indicated graph and the syntax is treated
as valid (no red outline in the query box). An update to the syntax
checking may be in order here.
* Using PerformUpdate I add new triples into http://tb-session . When
viewing the debugger’s “Input Graph” tab, I do not see this graph
listed. As a side note, the “subject”, “predicate”, “object” columns
in this tab should be sortable.
* A PerformUpdate cannot be used following an ApplyConstruct because
the URI of the constructed graph is unknown –I think even undefined.
Is this correct, or is there a way to determine the graph URI (I can
not query it or view it in the debugger). I like to use
ApplyConstruct in lieu of PerformUpdate for the sml:replace = true
option (which I assume will save memory when large input graphs are
used, faster than filtering or deleting downstream). An option to
specify a URI for the constructed graph would help here. And/Or have
sml:replace with the PerformUpdate module.
thank you,
-Daniel
--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
