Performance implications of using multiple named graphs for modular ontology

[jrh...@thematix.com]

I am working with an ontology (FIBO) which is currently structured into several dozen individual files that import each other. To simplify editing the ontology, I would like to put each module in a separate named graph so that it can be extracted for editing and then replaced. The ontology is likely to grow to several hundred modules.

I assume that Stardog will know how to resolve the imports declarations.

Is there a practical upper bound on the number of named graphs that the reasoner can be told to use?

Is there a performance implication on reasoning when the ontology is spread across several hundred named graphs?

Thanks, Jim

[Michael Grove]

On Wed, Apr 22, 2015 at 12:13 PM, <jrh...@thematix.com> wrote:

I am working with an ontology (FIBO) which is currently structured into several dozen individual files that import each other. To simplify editing the ontology, I would like to put each module in a separate named graph so that it can be extracted for editing and then replaced. The ontology is likely to grow to several hundred modules.

I assume that Stardog will know how to resolve the imports declarations.

No, Stardog ignores owl:imports declarations, you'd have to load them manually.

 

Is there a practical upper bound on the number of named graphs that the reasoner can be told to use?

No.

 

Is there a performance implication on reasoning when the ontology is spread across several hundred named graphs?

No.  The TBox is loaded into memory, and reasoning reduces to query answering.  So there's no more overhead than if you were querying over lots of graphs, which is to say, not much.

What's the expressivity of FIBO?

Cheers,

Mike

 

Thanks, Jim

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[Evren Sirin]

On Wed, Apr 22, 2015 at 12:13 PM, <jrh...@thematix.com> wrote:

> I am working with an ontology (FIBO) which is currently structured into
> several dozen individual files that import each other. To simplify editing
> the ontology, I would like to put each module in a separate named graph so
> that it can be extracted for editing and then replaced. The ontology is
> likely to grow to several hundred modules.
> I assume that Stardog will know how to resolve the imports declarations.

Stardog does not do anything with owl:imports statements. There is a
configuration option reasoning.schema.graphs [1] that determines which
named graphs are used to extract the schema and as of Stardog 3.0 the
default value is all named graphs. Therefore, as long as you load all
the ontologies into Stardog and don't change the default settings they
will be used by the reasoner.

> Is there a practical upper bound on the number of named graphs that the
> reasoner can be told to use?

Not really. But unless you have a good reason to exclude some
ontologies/named graphs, keeping the default setting to use all named
graphs is better than enumerating each named graph separately.

> Is there a performance implication on reasoning when the ontology is spread
> across several hundred named graphs?

No, the number of named graphs does not affect the performance but the
size of the overall schema does. As of version 3.0.1 Stardog includes
optimizations for very large schemas (millions of axioms), See this
section [2] under performance hits for working with large schemas.

Best,
Evren

[1] http://docs.stardog.com/#_configuration_options
[2] http://docs.stardog.com/#_very_large_schemas