Separation between TBox and ABox in Fuseki with TDB and Pubby - sparql

For my current project I need to load a dataset and different ontologies and expose everything as linked data using Fuseki with TDB and Pubby. Pubby will take a data set from a single location and create URIs based on that location, therefore if we need multiple different locations (as in the case with 2–3 separate ontologies), that would be easy to do with Pubby by adding another data set.
The concept of dataset seems to also apply to Fuseki.
Essentially I will need to expose three types of URIs:
www.mywebsite.com/project/data
www.mywebsite.com/project/data/structure
www.mywebsite.com/project/ontology
In order to create such URIs with Pubby 0.3.3. you will have to specify lines like these:
conf:dataset [
conf:sparqlEndpoint <sparql_endpoint_url_ONE>;
conf:sparqlDefaultGraph <sparql_default_graph_name_ONE>;
conf:datasetBase <http://mywebsite.com/project/>;
conf:datasetURIPattern "(data)/.*";
(...)
]
Each data set specified in Pubby will take its data from a certain URL (typically a SPARQL endpoint).
For ontologies you will have a dataset that uses the second a datasetURIPattern like this one:
conf:dataset [
conf:sparqlEndpoint <sparql_endpoint_url_TWO>;
conf:sparqlDefaultGraph <sparql_default_graph_name_TWO>;
conf:datasetBase <http://mywebsite.com/project/>;
conf:datasetURIPattern "(ontology)/.*";
(...)
]
As you can see the differences would be at the following: conf:sparqlEndpoint (the SPARQL endpoint), conf:sparqlDefaultGraph (the default Graph), conf:datasetURIPattern (needed for creating the actual URIs with Pubby).
It is not however clear to me how can I have separate URIs for the data sets when using Fuseki. When using Sesame, for example, I just create two different repositories and this trick works like charm when publishing data with Pubby. Not immediately clear with
The examples from the official Fuseki documentation present a single dataset (read-only or not, etc), but none of them seem to present such a scenario. There is no immediate example where there is a clear separation between the TBox and the ABox, even though this is a fundamental principle of Linked Data (see Keeping ABox and TBox Split).
As far as I understand this should be possible, but how? Also is it correct that the TBox and ABox can be reunited under a single SPARQL endpoint later by using (tdb:unionDefaultGraph true ;).

The dataset concept is not unique to Jena Fuseki; it's quite central in SPARQL. A dataset is a collection of named graphs and a default graph. The prefix of a URI has nothing to do with where triples about it are stored (whether in a named graph or in the default graph).
It sounds like you want to keep your ABox triples in one named graph and your TBox triples in another. Then, if the default graph is the union of the named graphs, you'll see the contents of both in the default graph. You can do that in Fuseki.

Related

REST GET mehod: Can return a list of enriched resources?

I have a doubt when I'm designing a REST API.
Consider I have a Resource "Customer" with two elements in my server, like this:
[
{
name : "Mary",
description : "An imaginary woman very tall."
},
{
name : "John",
description : "Just a guy."
}
]
And I want to make an endpoint, that will accept a GET request with a query. The query will provide a parameter with a value that will make an algorithm count how many occurrences for this text are there in all of its parameters.
So if we throw this request:
GET {baseURL}/customers?letters=ry
I should get something like
[
{
name : "Mary",
description : "An imaginary woman very tall.",
count : 3
},
{
name : "John",
description : "Just a guy.",
count : 0
}
]
Count parameter can not be included in the resource scheme as will depend on the value provided in the query, so the response objects have to be enriched.
I'm not getting a list of my resource but a modified resource.
Although it keeps the idempotent condition for GET Method, I see it escapes from the REST architecture concept (even the REST beyond CRUD).
Is it still a valid endpoint in a RESTful API? or should I create something like a new resource called "ratedCustomer"?
REST GET mehod: Can return a list of enriched resources?
TL;DR: yes.
Longer answer...
A successful GET request returns a representation of a single resource, identified by the request-target.
The fact that the information used to create the representation of the resource comes from multiple entities in your domain model, or multiple rows in your database, or from reports produced by other services... these are all implementation details. The HTTP transfer of documents over a network application doesn't care.
That also means that we can have multiple resources that include the same information in their representations. Think "pages in wikipedia" that duplicate each others' information.
Resource identifiers on the web are semantically opaque. All three of these identifiers are understood to be different resources
/A
/A?enriched
/B
We human beings looking at these identifiers might expect /A?enriched to be semantically closer to /A than /B, but the machines don't make that assumption.
It's perfectly reasonable for /A?enriched to produce representations using a different schema, or even a different content-type (as far as the HTTP application is concerned, it's perfectly reasonable that /A be an HTML document and /A?enriched be an image).
Because the machines don't care, you've got additional degrees of freedom in how you design both you resources and your resource identifiers, which you can use to enjoy additional benefits, including designing a model that's easy to implement, or easy to document, or easy to interface with, or easy to monitor, or ....
Design is what we do to get more of what we want than we would get by just doing it.

SQL, Link to Element Feature

I have two classes. One Attribut of class1 is connected to another attribut of class2. This was done with the help of the context menue of the connector in the proximity of one class, it is called Link to element feature. The same is done on the other side of the connector to select the other attribut of the other class. So the connector directly connects two attributes and not the classes itselves. I haven´t found the tables, where this infomation is stored, so I dont find the appropiate SQL to find connected (or not connected) attributes.
Here's the way for notes using Link to..
PDATA1 = 'Attribute'
PDATA2 = t_attribute.ID of the attribute
PDATA3 = name of the attribute
PDATA4 has 'Yes' (I don't recall what that's used for so you can probably ignore it
First SQL:
SELECT PDATA2 FROM t_object WHERE Object_Type='Note' AND PDATA1 = 'Attribute'
will give you the ID. Just put that in another SQL:
SELECT * FROM t_attribute WHERE ID = (above SQL)
and you have the attribute details. Or if you want to find the unmapped one just build a dissection with the found IDs from the first with the existing attribute IDs.
For associations using Link to... it's a bit more tricky. First off, any such connectors have the relevant information stored in t_connector.StyleEx like e.g.
LFEP={69A30E17-23AB-4641-9573-9BDBAA988D52}L;
LF<dir>P=<guid><pos>; connector is attached to attribute/operation
<dir> = S or E meaning Start (source) or End (target) <guid> = ea_guid of t_attribute or t_operation
<pos> is the edge (L or R) where the connector had been attached to in the moment when the link has been created. This is a superfluous information since the renderer will attach the link to whatever place is relevant.
There can be one LFSP, one LFEP or both be present in one StyleEx property
(from my Inside book)
Now you can filter that information with a SQL or (what I prefer) with a little script, since doing complex SQL string operations are not my expertise.

What's the difference between DENetworkDataset and NetworkDataset in ArcObjects?

In ArcObjects, there are two Coclasses which are similar with each other: DENetworkDataset and NetworkDataset , and GetDataElementFromNetworkDataset can transform NetworkDataset to DENetworkDataset, which is:
IDENetworkDataset GetDataElementFromNetworkDataset(INetworkDataset networkDataset)
{
IDatasetComponent datasetComponent = networkDataset as IDatasetComponent;
return (datasetComponent.DataElement as IDENetworkDataset);
}
However, what's the difference between these two datasets?
The DENetworkDataset is a light weight object that holds information about a network dataset.
If you check the ESRI documentation about IDENetworkDatase and INetworkDataset you can see that the first provides access to members that describe network dataset data elements and the second one provides access to members that query the schema of the network dataset.
They have different properties and methods, so it depends what do you want to do.

Create and connect individuals with an OWL DL reasoner

I have an ontology with different type of events.
Therefore I have three classes: A, B, C and a helper class Temp.
I want the reasoner to create a new individual as a subclass of C for every pair of individuals a (rdf:typeOf A) and b (rdf:typeOf B) found. This new Individuals should contain informations about a and b.
In the past I used a jena reasoner with an own rule file to get this result, but now I want to switch over to a standard OWL DL reasoner.
My initial idea is to link a und b such as:
a onto:hasB b
And ad give a the Type Temp with the following restriction for Temp:
hasbB some B
Now I want to create a new individual of type C with a restriction for Temp:
hasC some C
And over this new indivual I can access the informations of a and b.
My Problems are:
How can I get the reasoner to connect a and b?
I don't think the creation of C will work, since its a restriction for Temp, which will never be assigned as a type because of this restriction.
Or am I completly wrong with my approach?
Edit:
To clarify my goal with a better exmple:
I have an ontology with different type of events.
My goal is to connect certain individuals (events) which belong together by forming a new individual (event) describing this relation with the help of a reasoner.
E.g.:
I read an event (individual) which describes an "Alarm" (type) into the ontology.
I read an event (individual) which discribes a "PowerOutage" (type) into the ontology.
These Individuals aren't related at all at this moment.
Now I want a reasoner to create a new event (individual) with the type "PowerManipulation". In fact I want an individual with the type "PowerManipulation" created for every pair (which isn't connected, yet) of individuals with the type "PowerOutage" and "Alarm" found. These new individuals should have references (properties) to the individual which caused their creation (an "Alarm" and a "PowerOutage").
Ontology before the reasoning:
(alarm1 rdf:type "Alarm")
(out1 rdf:type "PowerOutage")
What I want the ontology to look like after the reasoning
(alarm1 rdf:type "Alarm")
(out1 rdf:type "PowerOutage")
(man1 rdf:type "PowerManipulation")
(man1 ont:hasRealtadInd alarm1)
(man1 ont:hasRealtedInd out1)
Priviously I used Jena rules and the Jena reasoner to accomplish this task.
But I want to switch over to a standard OWL DL reasoner.
Is it possible to accomplish this task with basic restrictions?
Or do I need SWRL rules, or SPIN (see Williams answer below)?
You can do this with SPIN constructors quite easily and SPIN inserts.
http://www.w3.org/Submission/2011/SUBM-spin-modeling-20110222/#spin-rules-construct
http://www.w3.org/Submission/2011/SUBM-spin-modeling-20110222/#spin-rules-update
SPIN and OWL can live happily together. Take a look at the groovy library that has extensions for both:
https://github.com/williamgreenly/lescot
Example below:
def model = new GroovyRdfModel()
model.add(""" some turtle data """)
model.add(""" some OWL rules """)
model.add(""" some SPIN rules """)
def inferredModelByOWLReasoning = model.owl()
def inferredModelBySPINRules = model.spin()

no inferences with DL queries in OWL - API

I am trying to write a query
Hospitals and hasNameWithWords value "center"^^string
This query returns me the instances that has the hospitals that has "center" in its name in Protege 4.2 with FACT++ reasoner as well as Hermit reasoner
but when i input the same query in the OWL-API's DL Query Example thats available in the website
http://sourceforge.net/p/owlapi/code/ci/aef6981535f07a2d0d44c394b9f4d5415f36025a/tree/contract/src/test/java/org/coode/owlapi/examples/DLQueryExample.java
I don't get any result.
But it gives me result when i write simple queries such as
Hospitals
Is it because the reasoner in the code is not able to make the inference?
What other reasoner would be better?
The class you use as example (DLQueryExample.java) relies on an OWL-API built-in structural reasoner (OWLReasonerFactory reasonerFactory = new StructuralReasonerFactory();).
This type of reasoner is fairly simple and is not suited for complex queries as yours. It can however provide answers on the class hierarchy: This is why you get some results with the straightforward query Hospitals.
What you need to do is to set your code to either use Hermit or FACT++. I give the example with Hermit:
Download HermiT jar file and add it to the class path of your project.
In your class, replace the line OWLReasonerFactory reasonerFactory = new StructuralReasonerFactory(); by: OWLReasonerFactory reasonerFactory = new Reasoner.ReasonerFactory();. You should have to import org.semanticweb.HermiT.Reasoner in order to make it work.
We just replaced the default reasoner by HermiT. The rest of the code should stay the same and your query should now work.
You could try FaCT++ and Pellet and compare speed, etc...