Is there a best practice for defining a literal with a language tag and a gender declension?
I couldn't find if there is a native solution for this.
We're using SPARQL and TriG, so a pseudo example of what I'm trying to achieve would be (using TriG):
content:data2
a k_content:Data;
content:content "איך אתה מרגיש?"#he-male ;
content:content "איך את מרגישה"#he-female .
Would #he-female / #he-male be a big no no? How did you address this?
As #AKSW suggested one approach is using an intermediate node
content:data2
a k_content:Data;
content:content [
rdf:value "איך אתה מרגיש?"#he ;
content:declension gender:male
];
content:content [
rdf:value "איך את מרגישה"#he;
content:declension gender:female
]
Another approach is to use dedicated (sub-)properties:
content:data2
a k_content:Data;
content:content-male "איך אתה מרגיש?"#he ;
content:content-female "איך את מרגישה"#he .
The ontology (T-Box) could contain the following:
content:content-female rdfs:subPropertyOf content:content .
content:content-intersex rdfs:subPropertyOf content:content .
content:content-male rdfs:subPropertyOf content:content .
I agree that label characteristics should be stored in separate fields. The Lemon ontology provides appropriate fields, and the OLIA and GOLD (ISO DCR) provide values. (OLIA probably also has appropriate fields)
Related
I am currently trying to build a constraint validation shape for an incoming object of the type rdf:Seq. The shacl shapes I have used, use the path to identify triple and then add additional constraint validations on datatype, length and count. But, with the case of rdf:Seq the predicate is a variable, it can be rdf:_1, rdf:_2,.... . How can I build an effective shape where I would not know how many elements would be present in the incoming rdf:Seq object?
Or is there a way I can check that if the predicate is of the type rdfs:ContainerMembershipProperty I can validate the datatype of the data, otherwise ignore it?
Appreciate any help. Thanks!
Let's say for a given incoming data
...
<incoming node> schema:colors _:blankNode1 .
_:blankNode1 rdf:type rdf:Seq .
_:blankNode1 rdf:_1 "Red" .
_:blankNode1 rdf:_2 "Blue" .
_:blankNode1 rdf:_3 "Yello" .
...
What could the shape be?
I was trying the following
...
sh: property [
sh:path schema:colors ;
sh:class rdf:Seq ;
sh:property [
sh:path <ideally would like a regex here> ;
# or a way to identify the path to data tripe
sh:in ("Red" "Blue" "Green" ) ;
] ;
] ;
...
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 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've been testing Sesame 2.7.2 and I got a big surprise when faced to the fact that DESCRIBE queries do not include blank nodes closure [EDIT: the right term for this is CBD for concise bounded description]
If I correctly understand, the SPARQL spec is quite loose on that and says that what is returned is actually up to the provider, but I'm still surprised at the choice, since bnodes (in the results of the describe query) cannot be used in subsequent SPARQL queries.
So the question is: how can I get a closed description of a resource <uri1> without doing:
query DESCRIBE <uri1>
iterate over the result to determine which objects are blank nodes
then DESCRIBE ?b WHERE { <uri1> pred_relating_to_bnode_ ?b }
do it recursively and chaining over as long as bnodes are found
If I'm not mistaken, depth-2 bnodes would have to be described with
DESCRIBE ?b2 WHERE {<uri1> <p1&> ?b . ?b <p2> ?b2 }
unless there is a simpler way to do this?
Finally, would it not be better and simpler to let DESCRIBE return a closed description of a resource where you can still obtain the currently returned result with something like the following?
CONSTRUCT {<uri1> ?p ?o} WHERE {<uri1> ?p ?o}
EDIT: here is an example of a closed result I want to get back from Sesame
<urn:sites#1> a my:WebSite .
<urn:sites#1> my:domainName _:autos1 .
<urn:sites#1> my:online "true"^^xsd:boolean .
_:autos1 a rdf:Alt .
_:autos1 rdf:_1 _:autos2
_:autos2 my:url "192.168.2.111:15001"#fr
_:autos2 my:url "192.168.2.111:15002"#en
Currently: DESCRIBE <urn:sites#1> returns me the same result as the query CONSTRUCT WHERE {<urn:sites#1> ?p ?o}, so I get only that
<urn:sites#1> a my:WebSite .
<urn:sites#1> my:domainName _:autos1 .
<urn:sites#1> my:online "true"^^xsd:boolean .
Partial solutions using SPARQL
Based on your comments, this isn't an exact solution yet, but note that you can describe multiple things in a given describe query. For instance, given the data:
#prefix : <http://example.org/> .
:Alice :named "Alice" ;
:likes :Bill, [ :named "Carl" ;
:likes [ :named "Daphne" ]].
:Bill :likes :Elaine ;
:named "Bill" .
you can run the query:
PREFIX : <http://example.org/>
describe :Alice ?object where {
:Alice :likes* ?object .
FILTER( isBlank( ?object ) )
}
and get the results:
#prefix : <http://example.org/> .
:Alice
:likes :Bill ;
:likes [ :likes [ :named "Daphne"
] ;
:named "Carl"
] ;
:named "Alice" .
That's not a complete description of course, because it's only following :likes out from :Alice, not arbitrary predicates. But it does get the blank nodes named "Carl" and "Daphne", which is a start.
The larger issue in Sesame
It looks like you're going to have to do something like what's described above, and possibly with multiple searches, or you're going to have to modify Sesame. The alternative to writing some creative SPARQL is to change the way that Sesame implements describe queries. Some endpoints make this relatively easy, but Sesame doesn't seem to be one of them. There's a mailing list thread from 2011, Custom SPARQL DESCRIBE Implementation, that seems addressed at this same problem.
Roberto García asks:
I'm trying to customise the behaviour of SPARQL DESCRIBE queries.
I'm willing to get something similar to CBD (i.e. all properties and
values for the described resource plus all properties and values for
the blank nodes connected to it).
I have tried to reproduce a similar behaviour using a CONSTRUCT query
but the performance is not good and the query gets quite complex if I
try to consider long chains of properties pointing to blank nodes
starting from the described resource.
Jeen Broekstra replies:
The implementation of DESCRIBE in Sesame is hardcoded in the query
parser. It can only be changed by adapting the parser itself, and even
then it will be tricky, as the query model has no easy way to express it
either: it needs an extension of the algebra.
> If this is not possible, any advice about how to implement it using CONSTRUCT
queries?
I'm not sure it's technically possible to do this in a single query.
CBDs are recursive in nature, and while SPARQL does have some support
for recursivity (property chains), the problem is that you have to do an
intermediate check in every step of the property chain to see if the
bound value is a blank node or not. This is not something that SPARQL
supports out of the box: property chains are defined to have only length
of the path as the stop condition.
Perhaps something is possible using a convoluted combination of
subqueries, unions and optionals, but I doubt it.
I think the best workaround is instead to use the standard DESCRIBE
format that Sesame supports, and for each blank node value in that
result do a separate consecutive query. In other words: you solve it by
hand.
The only other option is to log a feature request for support of CBDs in
Sesame. I can't give any guarantees about if/when that will be followed
up on though.
I am using the Jena semantic web framework version 2.6.3. I have code that creates a model with owl inferencing and then adds the following triples:
_:bnode-3 rdf:type owl:Restriction .
_:bnode-3 owl:onProperty :offspringOf .
_:bnode-3 owl:someValuesFrom :Person .
_:bnode-3 rdfs:subClassOf :Person .
_:bnode-3 is supposed to be a restriction class which, for example, would contain :joe if :bob is a :Person and the following triple were asserted:
:joe :offspringOf :bob .
Then, since the restriction class is a subclass of Person, :joe would also be a person.
And, in fact, this works. What's confusing to me is that after I assert just the 4 triples at the top of this post, the inferencer creates a blank node which is a Person. In other words, the following triple is now in the model:
_:b0 rdf:type :Person
I don't understand why it would do this. Any help in understanding this would be greatly appreciated.
Thanks.
Kent.
I am not sure why the inferencer would do this as I am not an OWL expert - have you tried asking your question on the jena-users lists?
They will usually answer you pretty promptly and they should know why you get the observed behaviour.
Note
I reformatted your question as your code samples were somewhat confusing - please don't write out Triples as [ex:subject ex:predicate ex:object] since it looks rather like some syntactic sugar in Turtle/N3/SPARQL which would result in additional Blank Nodes being created beyond just those you intended