# Reasoning via set graph

**URL:** <https://community.stardog.com/t/reasoning-via-set-graph/380>\
**Category:** Bug\
**Created:** [June 5, 2017, 8:59am UTC](https://community.stardog.com/t/reasoning-via-set-graph/380 "2017-06-05T08:59:05Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Alex](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Alex](https://community.stardog.com/u/Alex)\
**Post date:** [June 5, 2017, 8:59am UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/1 "2017-06-05T08:59:05Z")

</div>

Hi. I have Stardog 4.2.4, and i created two named graph (urn:graph1, urn:graph2). When i run query to first graph with reasoning, i see inferences both graphs.

First graph set query:

```
insert data {
    graph <urn:graph1> {
        <urn:Class1> a owl:Class .
        <urn:Class2> a owl:Class .

        <urn:Class1> rdfs:subClassOf <urn:Class2> .
    }
}

```

Second graph set query:

```
insert data {
    graph <urn:graph2> {
        <urn:class3-0001> a owl:NamedIndividual .
        <urn:class3-0001> a <urn:Class3> .
    }
}

```

Query with first graph:

```
select * from <urn:graph1> where {
	?subClass <tag:stardog:api:property:directSubClassOf> ?class .
}

```

Result:

```
subClass class

<urn:Class1>	<urn:Class2>
<urn:Class3>	owl:Thing
owl:Nothing <urn:Class1>
owl:Nothing <urn:Class3>
<urn:Class2>	owl:Thing

```

Why the result is present urn:Class3? This is a bug?

---

<div class="post-metadata">

**Author:** ![zachary.whitley](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/zachary.whitley/32/94_2.png) [@zachary.whitley](https://community.stardog.com/u/zachary.whitley)\
**Post date:** [June 5, 2017, 2:29pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/2 "2017-06-05T14:29:10Z")

</div>

Can you describe what part of the output is causing the confusion?

---

<div class="post-metadata">

**Author:** ![Alex](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Alex](https://community.stardog.com/u/Alex)\
**Post date:** [June 5, 2017, 2:38pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/3 "2017-06-05T14:38:18Z")

</div>

Graph 1 not includes info about urn:Class3. I have many graphs and in each graph different data and rules.

---

<div class="post-metadata">

**Author:** ![zachary.whitley](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/zachary.whitley/32/94_2.png) [@zachary.whitley](https://community.stardog.com/u/zachary.whitley)\
**Post date:** [June 5, 2017, 3:16pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/4 "2017-06-05T15:16:37Z")

</div>

I can see how that would be a little confusing. I’d have to look closely at the specs to see if that’s correct or not but I’ll let someone else who is more knowledgeable jump in. It might be correct if the extracted TBOX is added to the context of the query as possible solutions.

---

<div class="post-metadata">

**Author:** ![Alex](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Alex](https://community.stardog.com/u/Alex)\
**Post date:** [June 6, 2017, 11:33am UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/5 "2017-06-06T11:33:05Z")

</div>

If i set TBOX to only urn:graph1, that result remains the same.

---

<div class="post-metadata">

**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\
**Post date:** [June 7, 2017, 9:06am UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/6 "2017-06-07T09:06:34Z")

</div>

Once extracted, the schema is global for the database and results of the _schema_ queries, including triple patterns with the special predicates, are not affected by `FROM`, `FROM NAMED`, or `GRAPH` clauses in the query.

We’ll improve the documentation to make this clearer.

Cheers,  
Pavel

---

<div class="post-metadata">

**Author:** ![zachary.whitley](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/zachary.whitley/32/94_2.png) [@zachary.whitley](https://community.stardog.com/u/zachary.whitley)\
**Post date:** [June 7, 2017, 10:32am UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/7 "2017-06-07T10:32:13Z")

</div>

When you say you set TBOX to only urn:graph1 do you mean that you set the reasoning.schema.graphs to urn:graph1 or was there something about your query that you thought was restricting the TBOX?

Pavel, if they set reasoning.schema.graphs to urn:graph1 is there a possibility that Stardog is not re-extracting the schema when that option is being changed?

---

<div class="post-metadata">

**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\
**Post date:** [June 7, 2017, 11:11am UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/8 "2017-06-07T11:11:59Z")

</div>

This option can only be set when the database is taken offline first. Schema should be re-extracted when the database is brought back online.

The schema is still global though, even when it’s extracted from a subset of named graphs. AFAICT, this the thing that causes confusion here.

Cheers,  
Pavel

---

<div class="post-metadata">

**Author:** ![zachary.whitley](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/zachary.whitley/32/94_2.png) [@zachary.whitley](https://community.stardog.com/u/zachary.whitley)\
**Post date:** [June 7, 2017, 2:14pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/9 "2017-06-07T14:14:47Z")

</div>

I gave the example provided a try and tried setting reasoning.schema.graphs to urn:graph1 and when running the query provided

> select \* from \<urn:graph1\> where {  
> ?subClass \<tag:stardog:api:property:directSubClassOf\> ?class .  
> }

get back urn:Class3 which is only contained in urn:graph2 which seems odd.

---

<div class="post-metadata">

**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\
**Post date:** [June 7, 2017, 2:46pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/10 "2017-06-07T14:46:54Z")

</div>

Seems like graph IRIs are lost from your last message.

---

<div class="post-metadata">

**Author:** ![zachary.whitley](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/zachary.whitley/32/94_2.png) [@zachary.whitley](https://community.stardog.com/u/zachary.whitley)\
**Post date:** [June 7, 2017, 3:30pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/11 "2017-06-07T15:30:23Z")

</div>

Whoops, it looks like the angle brackets are picked up as markup.

I gave the example provided a try and tried setting reasoning.schema.graphs to `<urn:graph1>`and when running the query provided

```
select * from <urn:graph1> where {
?subClass <tag:stardog:api:property:directSubClassOf> ?class .
}

```

get back `<urn:Class3>` which is only contained in `<urn:graph2>` which seems odd.

---

<div class="post-metadata">

**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\
**Post date:** [June 7, 2017, 8:02pm UTC](https://community.stardog.com/t/reasoning-via-set-graph/380/12 "2017-06-07T20:02:54Z")

</div>

Yes, there’s another thing going on here.

In addition to loading axioms and rules, Stardog also extracts class and property names which aren’t explicitly declared and don’t occur in TBox axioms. For example, `:s rdf:type :A` implies that `:A` is a class (under the RDFS semantics). Stardog runs queries against the _full_ database to extract such untyped terms, and that’s how `<urn:Class3>` ended up in the schema.

I agree that ignoring `reasoning.schema.graphs` while doing it could be confusing because some parts of the schema (albeit trivial) come from outside of the schema graphs. OTOH, running such queries against the schema graphs would be useless in many cases since data is often stored separately from the schema.

I’ll create a ticket to provide more options to either disable this behavior or restrict it to particular graphs.

Cheers,  
Pavel