Dave, see responses inline:
On Apr 7, 3:09 pm, DaveL <[email protected]> wrote:
> Thanks, Scott, that helps clarify the usage model.
>
> Unfortunately, I'm still having some issues.
>
> 1. My database contains named graphs which correspond to ontologies;
> this is a feature SDB permits to allow you to reference an ontology
> stored in the database rather than having to load from a file. When I
> create the connection, I got an error that it couldn't find one (out
> of four) referenced ontologies in the database. The resulting
> connection didn't find much of anything.
If you have four ontologies (named graphs) then, you will need four
connector files, one for each named graph. If you want to access the
unnamed graph in SDB, you will need another connector file. Same for
accessing the union graph.
> 2. So, I imported the ontologies into my project from the files before
> creating the connection. This seemed to work better, but the resulting
> "Ontology Overview" complains that there are multiple owl:Ontologies
> in the model. It's not entirely clear from the popup explanation what
> it does in this case and how to work around it.
2a. The first sentence has thrown me off. What files are being added
to the workspace? If you create an SDB connection, the only thing
saved in your workspace is a .sdb file in Turtle format. It's about
20 lines and contains only connection information - i.e. how to get to
the database, log in and what (if any) named graph is being
accessed. The actual data is stored in the relational database of
your choice. Given the rest of your statements, I think this is
understood, so either clarification is needed or this is a source of
the issues.
2b. The multiple ontologies warning aligns the ontology statement and
baseURI statement of the connector. It is safe to ignore or click to
let the system take care of it.
> 3. Finally, I was able to run my query, but the GRAPH ?g returned is
> always the root URI of my database. Is this because the UnionGraph
> connection essentially copies everything into the default graph,
> thereby losing the "?g" info?
Yes, it is the case that the union graph is the union of all graphs in
the data set. Information on the graph the triple belongs to is not
included by SDB because it is a true union of the graphs - e.g. two
named graphs with the same triple will occur only once in the union
graph (triples) and twice if each named graph is queried separately
(quads).
Since the last response, we have discovered that there is a defect in
that prevents the following kind of query from being executed
reliably. Apologies for the confusion this may have caused. In TBS
3.5 (beta in a couple of weeks) you will be able to do the following:
SELECT *
FROM NAMED <base URI of .sdb 1>
FROM NAMED <base URI of .sdb 2>
FROM NAMED <base URI of .sdb 1>
WHERE
{ GRAPH ?g {?s ?p ?o}
}
...where FROM NAMED can refer to any base URI of any file in Composer/
Live's workspace, including data connector files. We are also
investigating ways to more conveniently access the full set of named
graphs in a given data store. SDB supports the union graph, but this
is not universally adopted and we are investigating options. In the
meantime the one-connector-per-named-graph has the advantage that
connector files can be used to mix-and-match graph inclusion as needed
for owl:imports, SPARQL queries, etc.
> 4. It still doesn't work to re-open a connection file one has created
> and saved. The error is as reported in my first message. The only
> workaround is to create a new connection file with a different name or
> restart TBC.
I'd like to understand a little more about what is happening in item
2) before addressing this. Re-opening connector files works reliably
in TBC-ME 3.4.0.
> 5. Bug report: very few of your windows, most importantly error
> message pop-ups, permit you to copy/paste out of them. Makes life
> tedious.
All errors, along with warnings and some informational messages are
found in the Error Log. Open this view in Window > Show View >Error
Log. Double-click on a message to get a pop-up that you can copy,
along with some nice buttons to copy to the clipboard, etc.
-- Scott
> Thanks,
>
> Dave
>
> On Apr 6, 1:34 pm, Scott Henninger <[email protected]> wrote:
>
> > Ok, thanks for the clarifications. The first thing to understand is
> > that these examples are created from a database perspective where the
> > query is applied to a database with some named graphs. When using
> > TopBraid Composer or Live, you are using a server perspective where
> > there can be multiple database references, file serializations, etc.
> > To access a named graph in one of those databases necessarily involves
> > a level of indirection: you need to identify the database and the
> > named graph.
>
> > For SDB, there are three different contexts for named graphs to
> > consider:
> > 1) an unnamed graph - this is a separate graph that does not have a
> > name (triples only, not a quad)
> > 2) a named graph (quad storage)
> > 3) the union of all graphs
>
> > Note that 1) and 3) are different. The union graph will include the
> > unnamed graph and all named graphs.
>
> > Given this, you can set the context of a query to the union graph for
> > the SDB database with the FROM statement in SPARQL:
>
> > SELECT *
> > FROM <base URI of union graph>
> > WHERE {
> > GRAPH ?g {?s ?p ?o}
>
> > }
>
> > The second step is to get the base URI of the union graph for your SDB
> > data store. To do this create a connector file (New > Jena SDB
> > connector) that specifies "urn:x-arq:UnionGraph" as the SDB Named
> > Graph URI.
>
> > The use of connector files may need a bit of explanation. It's key to
> > understand that Composer/Live use a named graph structure throughout
> > its workspace, using the base URI as the name of the graph. This not
> > only addressed the indirection necessary to address multiple
> > databases, but integrates nicely with owl:imports which also uses URIs
> > to identify the imported graphs. Each connector creates a base URI
> > that holds information about what data set (where a "data set" can be
> > anything that has a named graph structure) to address and the named
> > graph within that data set. This goes for the union graph, which is a
> > specific type of graph in SDB, as well as named (and unnamed) graphs.
>
> > Again, the added level of indirection is necessary because Composer is
> > using a server model (workspace consisting of many connections) and
> > the examples are using a single data store model (one connection).
>
> > -- Scott
>
> > On Apr 6, 9:58 am, DaveL <[email protected]> wrote:
>
> > > Scott,
>
> > > I am using TBC 3.4.0.
>
> > > The general form of the query was taken
> > > fromhttp://www.cambridgesemantics.com/2008/09/sparql-by-example/#%2833%29
> > > .
>
> > > The exact query I am running (slightly edited to remove propriety
> > > information) is:
>
> > > PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> > > PREFIX cc: <http://anchor/example#>
> > > SELECT *
> > > WHERE
> > > {
> > > { ?s rdf:type cc:exampleType }
> > > UNION
> > > { GRAPH ?g { ?s rdf:type cc:exampleType } }
>
> > > }
>
> > > The intent is to return all named graphs which contain resources of
> > > rdf:type "exampleType."
>
> > > This query works perfectly when executed via the Jena/SDB
> > > QueryExecution class, by code (excerpted) here:
>
> > > Dataset ds = DatasetStore.create(store); // an SDB Store
> > > Query query = QueryFactory.create("---the above query---"));
> > > QueryExecution qe = QueryExecutionFactory.create(query, ds );
> > > try {
> > > ResultSet rs = qe.execSelect();
> > > ResultSetFormatter.out(rs);
> > > } finally {
> > > qe.close();
> > > }
>
> > > Thanks for any comments,
>
> > > Dave
>
> > > On Apr 5, 6:23 pm, Scott Henninger <[email protected]> wrote:
>
> > > > Dave; We'd need a couple of follow-up to look into this properly.
> > > > First is what version of TBC-ME are you using? The second is what
> > > > specific query template are you using?
>
> > > > To access an existing SDB database, you'd need to use the same New >
> > > > RDF/OWL Jena SDB Database Connection, and fill in the information on
> > > > the relational database where the data is store. Note that this
> > > > wizard only creates a connection to an existing data store. There
> > > > aren't any stricter requirements for using a .sdb connector.
>
> > > > -- Scott
>
> > > > On Apr 5, 3:24 pm, DaveL <[email protected]> wrote:
>
> > > > > Having read the discussion last month about Named Graphs, I find
> > > > > myself still a bit confused.
>
> > > > > I'm developing an OWL app which uses SDB as the repository. In the
> > > > > repository are many Models which are named graphs representing
> > > > > resources, and some Models which are ontologies (referenced by the
> > > > > resources, via the SDB DocumentManager).
>
> > > > > I tried connecting to this pre-existing store from TBS (Maestro
> > > > > Edition), and had a couple of odd results.
>
> > > > > First, if I create the .sdb file using the wizard under New / RDF/OWL
> > > > > Jena SDB Database Connection, I can access the default graph (if I
> > > > > don't fill in the "Named Graph URI" field, or any specific graph if I
> > > > > put its URI in the field, but there doesn't appear to be a way to
> > > > > access the database as a whole. For example, I'd like to be able to
> > > > > query for all graphs which contain a triple matching a pattern. The
> > > > > template for doing this (in the SPARQL by example presentation)
> > > > > doesn't work for me.
>
> > > > > Second, re-opening an existing .sdb file never seems to work. An
> > > > > exception is invariably thrown:
>
> > > > > "Could not load \TopBraid\SDBRepository.sdb or one of its imports.
> > > > > The most recent URI washttp://localhost/dataStore
> > > > > No matching StoreCache entry found"
>
> > > > > Once I get this error I must restart TBS before I can look at the
> > > > > database again.
>
> > > > > Any guidance on what this means? Are there stricter requirements for
> > > > > the contents of the database than I am aware of, for example? (Things
> > > > > I must add to be TBS-compatible, for example. I note a reference in
> > > > > the .sdb file to a "config" model that I don't create...)
>
> > > > > Thanks,
>
> > > > > Dave Lebling
--
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