I'm doing some work with RDF Data Cubes vocabulary for publishing time-series of various data, among others sensors. The measurement of the sensor is taken at a specific time at a specific station.
Both time and station I will model as qb:DimensionProperty, the measurement itself as qb:MeasureProperty. I would also like to state what unit the measurement is in. In this particular example it is atmospheric pressure at the height of the station. My understanding from the spec is that this would be modeled as qb:AttributeProperty.
In the description of the data structure I would have something like this:
<dsd/prestas0> a qb:DataStructureDefinition ;
qb:component
[ qb:dimension <stn>; qb:order 1 ],
[ qb:dimension <time>; qb:order 2 ],
[ qb:attribute <unit>; qb:order 3 ],
[ qb:measure <prestas0>; qb:order 4 ] .
<stn> a qb:DimensionProperty ;
rdfs:label "Station°" .
<time> a qb:DimensionProperty ;
rdfs:label "Time" .
<unit> a qb:AttributeProperty ;
rdfs:label "Unit" ;
rdfs:comment "The unit of the measurement" .
<prestas0> a qb:MeasureProperty ;
rdfs:label "Measurement" ;
rdfs:range xsd:float .
# Units in use
<hPa> a qudt:Unit ;
rdfs:label "Atmospheric pressure (hPa)" ;
rdfs:comment "Atmospheric pressure on station level" ;
rdfs:subClassOf unit:Pascal .
As you can see I also created an instance of a unit, called <hPa>. In there I use rdfs:subClassOf to subclass from QUDT unit:Pascal.
Now my questions:
is my understanding of using qb:AttributeProperty for the unit correct?
Is it fine to sublass from QUDT the way I did? I am aware that I have hPa while QUDT defines Pa only so I would probably have to change the data accordingly
Can I in general simply use units from QUDT directly (in terms of their URIs) if they do not need a specific tailoring like I did in this example?
Related
I am new to SPIN. I wonder if it makes sense to use it for the following purpose. Say I have the following class hierarchy:
ex:Vehicle
ex:Car
ex:Sedan
Some classes have the property owl:equivalenClass set to some value, for example:
ex:Vehicle
owl:equivalentClass wd:MeanOfTransportation
ex:Sedan
owl:equivalentClass wd:Sedan
In the case owl:equivalentClass is not set to a value, it should take the value of it's parent class. In the above example:
ex:Car
owl:equivalentClass wd:MeanOfTransportation
Can this be accomplished with SPIN, in my case using TopBraid?
It makes sense to use SPIN for these purposes, because SPIN inference engine is the only inference engine available in TopBraid Composer Free Edition.
In other TopBraid Composer editions, the appropiateness, as well as the result obtained, may vary depending on your inferencing configuration (Inferences > Configure Inferencing).
The rule is:
rdfs:Class spin:rule [
rdf:type sp:Construct ;
sp:text """
CONSTRUCT {
?this owl:equivalentClass ?equivalentClass .
}
WHERE {
?this rdfs:subClassOf ?superClass .
?superClass owl:equivalentClass|^owl:equivalentClass ?equivalentClass .
FILTER NOT EXISTS {
?this owl:equivalentClass|^owl:equivalentClass [] .
}
} """
] .
Please note that this SPIN rule is attached to rdfs:Class : a class that instances all these ex:Car, ex:Vehicle are.
?this is a special variable that refers to the "current" instance of this class.
It seems that the spl:InferDefaultValue SPIN template can not be used in your case, because spl:InferDefaultValue doesn't accept SPARQL variables as its spl:defaultValue argument.
I have a following problem to model in OWL using Protégé:
Multiple Songs could be performed in different Performances. Each Song could be arranged by different Arranger in different Performance.
I already know how to relate a Song to a Performance using object property. Now, how to map a Song-Performance pair to an Arranger? (In relational database, I would call this as a "descriptive attribute" of a many-to-many Song-Performance relationship).
I know that I could use an annotation to an object property, but I would like to be able to infer something from this property. (For example: what Song has an Arranger arranged, and in which Performance?) As far as I know, I am not able to do inference from an annotation.
It's not necessary to add properties of properties to model this scenario, although a property is an object (a uri) and therefore can include any property, not just annotation properties. rdfs:subPropertyOf is a good example. Statement reification isn't necessary either. It's a matter of creating an object that holds information about the song and performance.
Here is a model that represents an Arranger's relationship to a Song-Performance:
ex:SongPerformance a owl:Class .
ex:Arranger a owl:Class .
ex:arranged rdfs:domain ex:Arranger ;
rdfs:range ex:SongPerformance .
ex:songPerformed rdfs:domain ex:SongPerformance ;
rdfs:range ex:Arranger .
ex:performedIn rdfs:domain ex:SongPerformance ;
rdfs:range ex:Arranger .
Given this list, an example instance is:
ex:Arranger-1 ex:arranged ex:SP1 .
ex:SP1 ex:performedIn ex:Performance_1 ;
ex:songPerformed ex:Song1 .
Then you can find which songs has an arranger arranged in a given performance through the following SPARQl query:
SELECT ?arranger ?song ?performance
WHERE {
?arranger a ex:Arranger ;
ex:arranged ?sp .
?sp ex:songPerformed ?song ;
ex:performedIn ?performance .
}
I have a RDF graph with several types of relations (relations with the same prefix and with different prefixes also). I need to call a service over the graph but filtering out some relations.
Example:
#prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
#prefix myPref: <http://www.myPref.com/>.
#prefix otherPref: <http://www.otherPref.com/>.
myPref:1
myPref:label "1" ;
myPref:solid myPref:2 ;
myPref:dotted myPref:4 ;
otherPref:dashed myPref:3 ;
otherPref:dashed2 myPref:3 .
myPref:2
myPref:label "2" ;
myPref:solid myPref:3 .
myPref:3
myPref:label "3" .
myPref:4
myPref:label "4" ;
myPref:dotted myPref:3 .
I would like to run the service call over an extracted sub-graph containing only the solid and dotted relations (In this particular case, running a service calculating the shortest path between 1 to 3, I want to exclude those direct links).
I run the service (Over the entire graph) like this:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
PREFIX myPref: <http://www.myPref.com/>.
PREFIX otherPref: <http://www.otherPref.com/>.
PREFIX gas: <http://www.bigdata.com/rdf/gas#>
SELECT ?sp ?out {
SERVICE gas:service {
gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" .
gas:program gas:in myPref:1 .
gas:program gas:target myPref:3 .
gas:program gas:out ?out .
gas:program gas:out1 ?sp .
}
}
How can I extract a subgraph containing only the links I want (Dotted and solid) and the run the service call over the extracted sub-graph?
SPARQL doesn't provide any functionality for querying a constructed graph, unfortunately. I've come across places where it would make some queries very easy. Some endpoints do have extensions to support it, though. I think that dotNetRDF might support it. There are probably a few aspects: in many cases, it's not actually necessary; if the endpoint supports updates, you can create a new named graph and construct into it, and then launch a second query against it (which is pretty much what you're asking for, but in two steps); this could be a very expensive operation, so endpoints might disable it anyway, even if it was directly supported.
The first note, though, that it's often times not necessary, appears that it might be the case here.
I need to call a service over the graph but filtering out some relations.
In this case, you can query over the subgraph that you want, I think, by using property paths. You can ask for paths built from just solid and dashed edges like:
?s myPref:solid|myPref:dotted ?t
If you want an arbitrary path of them, you can repeat it:
?s (myPref:solid|myPref:dotted)+ ?t
If you have unique paths between sources and destinations, then you can figure out the lengths of paths using the standard "count the ways of splitting the path" technique:
select (count(?t) as ?length) {
?s (myPref:solid|myPref:dotted)* ?t
?t (myPref:solid|myPref:dotted)* ?u
}
group by ?s ?t
I am doing some experiments with importing triples formulated in the turtle language
within the openrdf-workbench webapp in Tomcat, which has incorporated a SPARQL endpoint.
I wonder if with turtle, or, generally, in RDF / RDFS is it possible to add a certain predicate/object declaration on all (implicit) subjects conditionally to the existence of another predicate/object.
For example, if I have the following triples defined:
foo:a foo:b foo:c
foo:d foo:b foo:c
foo:e foo:b foo:c
foo:f foo:b foo:c
I would like to automatically add the following predicate/subject to all subjects that match predicate=foo:b and object=foo:c:
(implicit subject) foo:g foo:h
in order to automatically produce the following triples:
foo:a foo:g foo:h
foo:d foo:g foo:h
foo:e foo:g foo:h
foo:f foo:g foo:h
Is this possible?
Alternatively: is there any way to define some triples in order to enable SPARQL to find foo:a/d/e/f when queried for subjects that have foo:g foo:h as predicate/object?
Part 1 - Creating additional information
The first part of your question can be solved in one of two ways:
Using Inference
Using SPARQL Update
Inferencing
Inference is a technique whereby you define rules that infer additional triple based on your existing triples. You typically either use a pre-defined set of rules or use your own custom rules. I think Sesame only supports pre-defined rule sets out of the box so you may want to take a look at OWLIM which is an alternative back end that can be used with Sesame and has much more customisable rules AFAIK.
Inferencing can typically be applied in two ways, one where you only store the rules and you compute the additional information every time a rule fires and another where you pre-compute all the additional information and add it to your database. Which you will want to use depends on how you intend to use your system and there are performance trade offs involved. I'm not going into detail because that's really a whole other question - see Forward vs Backward Chaining for some discussion
SPARQL Update
Alternatively if your rules are relatively simple and you are OK with pre-computing the extra information and adding it to your database you can write SPARQL Updates to do this e.g.
PREFIX foo: <http://example.org/foo#>
INSERT
{
?x foo:g foo:h .
}
WHERE
{
?x foo:b foo:c .
}
Part 2 - Querying the Data
I am guessing you are fairly new to SPARQL because from what you've described this sounds trivial to me.
If I wanted to find all subjects which had the predicate foo:g and the object foo:h I would simply write the following:
PREFIX foo: <http://example.org/foo#>
SELECT ?x
WHERE
{
?x foo:g foo:h .
}
You can do this type of inference using OWL with an axiom of the form
p value a ⊑ q value b
which says that if something has a as a value for property p, then it also has b as a value for property q. As an example, here's an ontology with four individuals (a, b, c, d), two object properties (p, q), and the axiom (p value c ⊑ q value d).
#prefix : <http://example.org/add-predicate-object#> .
#prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
#prefix owl: <http://www.w3.org/2002/07/owl#> .
#prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
#prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<http://example.org/add-predicate-object> a owl:Ontology .
:p a owl:ObjectProperty .
:q a owl:ObjectProperty .
[ a owl:Restriction ;
owl:onProperty :p ;
owl:hasValue :c ;
rdfs:subClassOf [ a owl:Restriction ;
owl:onProperty :q ;
owl:hasValue :d ] . ] .
:a a owl:Thing, owl:NamedIndividual ; :p :c .
:b a owl:Thing, owl:NamedIndividual ; :p :c .
:c a owl:Thing, owl:NamedIndividual .
:d a owl:Thing, owl:NamedIndividual .
In Protégé, the axiom looks like this:
You can enable a reasoner and query for instances of q value d and see:
or you can browse to individuals and see the results:
I am studying the notion of OWL restrictions with Protege 4 using FaCT++ and a trivial ontology. Suppose I have an individual foo of class Something:
:Something a owl:Class.
:foo a :Something, owl:NamedIndividual.
and another class defined from a restriction on the hasBar property:
:hasBar a owl:ObjectProperty.
:SomethingElse owl:equivalentClass [a owl:Restriction;
owl:onProperty :hasBar;
owl:allValuesFrom :Something].
If I assert that:
:x :hasBar :foo.
why can't I infer from it that x is a SomethingElse (via the fact that foo is a Something)? The only way I can make it work is if the range of hasBar is defined:
:hasBar a owl:ObjectProperty;
rdfs:range :Something.
But I'd like to avoid that, because it puts a constraint on what can be the subject of hasBar (which causes me further trouble).
I think it is simpler to reason over real examples, let's consider the following knowledge base:
:eats rdf:type owl:ObjectProperty .
:Vegetable rdf:type owl:Class ;
rdfs:subClassOf owl:Thing .
:Vegetarian rdf:type owl:Class ;
owl:equivalentClass [ rdf:type owl:Restriction ;
owl:onProperty :eats ;
owl:allValuesFrom :Vegetable
] .
:Carrot rdf:type :Vegetable ,
owl:NamedIndividual .
:John rdf:type owl:NamedIndividual , owl:Thing ;
:eats :carrot .
You have some equivalences with your example: hasBar is eats, Vegetarian is SomethingElse, Vegetable is Something, foo is carrot and finally x is John.
Now you would like to infer that John is a Vegetarian (= x is SomethingElse).
It makes sense that it doesn't work with an owl:allValuesFrom. What you are saying here is that all instances of vegetarian, if they have a property, they must have Vegetable in range. So from that you could deduce that carrot is a vegetable for example, assuming you would know that John is a vegetarian in the first place.
It makes sense in natural language too: In your ontology you only know that John eats a carrot, this doesn't automatically make him a vegetarian (non-vegetarian people eat also carrots).
You could use a owl:someValuesFrom instead of a owl:allValuesFrom. This way, you would define every vegetarian has someone that eats some vegetable. In this case if we know that John eats a carrot, therefore he would be classified as vegetarian by the reasoner, based on your definition of the concept vegetarian.
Universal (allValuesFrom) and existential (someValuesFrom) restrictions are complicated to understand, there is often no right or wrong solution, it mostly depends to what you want to achieve.