Author: alexdma
Date: Wed Jan 18 14:01:15 2012
New Revision: 1232884
URL: http://svn.apache.org/viewvc?rev=1232884&view=rev
Log:
STANBOL-461 : trying to fix nested list in Markdown
Modified:
incubator/stanbol/site/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.mdtext
Modified:
incubator/stanbol/site/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.mdtext
URL:
http://svn.apache.org/viewvc/incubator/stanbol/site/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.mdtext?rev=1232884&r1=1232883&r2=1232884&view=diff
==============================================================================
---
incubator/stanbol/site/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.mdtext
(original)
+++
incubator/stanbol/site/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.mdtext
Wed Jan 18 14:01:15 2012
@@ -47,17 +47,17 @@ In a non-OSGi environment they must be i
Note that when you add an ontology to a space or session, you pass it an
`OntologyInputSource` object, or more precisely, an `OntologyInputSource<O,P>`.
This is because there can be several ways to obtain an ontology, and those most
common are supported in Stanbol. For example, it can be obtained by
defererencing a IRI and parsing its source code (in RDF/XML, Turtle, etc.), or
by reading an input stream, or taking an already stored RDF graph in the
Stanbol store; or it could be an ontology Java object created from scratch. An
__Ontology input source__ is an object that incorporates (1) the "method" by
which an ontology should be accessed; (2) the type of Java object it should
create to represent an ontology; (3) where it should store the ontology.
* __`OWLOntology` input sources__ comply with the OWL API specification <a
href="#ref1">[1]</a> and creates objects of type `OWLOntology` stored in an
_in-memory_ `OWLOntologyManager`. It will be stored persistently once added to
an ontology network.
-** `RootOntologySource`. Wraps an already existing `OWLOntology`, therefore it
does not provide a physical IRI.
-** `RootOntologyIRISource`. Tries to locate and load an ontology, and its
imports, from a given IRI. It can use a custom `OWLOntologyManager` as a store,
and can even override any mappers, in order to force-dereference the IRI.
-** `ParentPathInputSource`. Tries to load an ontology from a root `File`, and
will seek its imports among the files in the same directory as the root `File`.
It also allows a custom `OWLOntologyManager` as a store.
+ * `RootOntologySource`. Wraps an already existing `OWLOntology`, therefore
it does not provide a physical IRI.
+ * `RootOntologyIRISource`. Tries to locate and load an ontology, and its
imports, from a given IRI. It can use a custom `OWLOntologyManager` as a store,
and can even override any mappers, in order to force-dereference the IRI.
+ * `ParentPathInputSource`. Tries to load an ontology from a root `File`,
and will seek its imports among the files in the same directory as the root
`File`. It also allows a custom `OWLOntologyManager` as a store.
Loads the ontology source codeWraps an already existing `OWLOntology`,
therefore it does not provide a physical IRI.
-** `BlankOntologySource`. Creates an `OWLOntology` with no ID and no axioms.
It can be useful for supplying dummy ontologies to methods that will not admit
a null ontology. Note that the blank ontology is not shared: each
`BlankOntologySource` has a distinct blank ontology object, and they are _not_
equal! This means that the following statement is false:
+ * `BlankOntologySource`. Creates an `OWLOntology` with no ID and no
axioms. It can be useful for supplying dummy ontologies to methods that will
not admit a null ontology. Note that the blank ontology is not shared: each
`BlankOntologySource` has a distinct blank ontology object, and they are _not_
equal! This means that the following statement is false:
new BlankOntologySource().getRootOntology().equals(new
BlankOntologySource().getRootOntology());
* __`TripleCollection` input sources__ comply with the Apache Clerezza API
specification, which is also the default native implementation of OntoNet. The
resulting ontology is a subtype of `TripleCollection` (`Graph` or `MGraph`) and
uses a `TcProvider` as a store. Depending on the chosen Stanbol storage, it can
be pesistent or in-memory. Generally, these input sources take less memory that
OWL API counterparts, but do not allow RDF graphs to be managed using the OWL
language constructs. Note that any `TripleCollection` can be exported as an
`OWLOntology` afterwards, once stored.
-** `GraphContentInputSource`. Creates a `TripleCollection` by reading an input
stream, which can be obtained from a file, URL etc. It can use any `TcProvider`
as a store, otherwise it will create an in-memory triple collection, which will
be copied to the Stanbol store when adding the ontology to a network. If this
`TcProvider` is the `TcManager` used by Stanbol, its triples are not copied
across.
-** `GraphSource`. Wraps an existing `TripleCollection` object. In general, it
does not 'know' where the ontology was stored.
+ * `GraphContentInputSource`. Creates a `TripleCollection` by reading an
input stream, which can be obtained from a file, URL etc. It can use any
`TcProvider` as a store, otherwise it will create an in-memory triple
collection, which will be copied to the Stanbol store when adding the ontology
to a network. If this `TcProvider` is the `TcManager` used by Stanbol, its
triples are not copied across.
+ * `GraphSource`. Wraps an existing `TripleCollection` object. In general,
it does not 'know' where the ontology was stored.
### Service Endpoints