When generating a SPARQL query from the UI, an extra variable is added in the WHERE clause. Rest of the query would execute exactly as planned, if it was not for this "dangling variable".

Example:

PREFIX klex:
PREFIX rdf:
PREFIX foaf:
PREFIX dbprop:
PREFIX dc:
PREFIX rdfs:
SELECT DISTINCT ?artist_field_name ?artist_field_birthday ?artist_field_birthplace ?artist_field_deathday ?artist_field_deathplace ?artist_field_description ?artist ?artist_field_proflabel
WHERE {
?artist klex:hasOccupation ?artist_field_proflrel2; rdf:type ; foaf:Name ?artist_field_name.
?artist_field_proflrel2.
OPTIONAL {?artist dbprop:birthDate ?artist_field_birthday}
OPTIONAL {?artist dbprop:birthPlace ?artist_field_birthplace}
OPTIONAL {?artist dbprop:deathDate ?artist_field_deathday}
OPTIONAL {?artist dbprop:deathPlace ?artist_field_deathplace}
OPTIONAL {?artist dc:description ?artist_field_description}
OPTIONAL {?artist_field_proflrel2 rdfs:label ?artist_field_proflabel}
}
LIMIT 25

CommentFileSizeAuthor
#11 1273346-10-support-optional-relationships.patch5.94 KBstuartraetaylor
#10 1273346-10-support-optional-relationships.patch5.96 KBstuartraetaylor

Comments

Anonymous’s picture

Anonymous (not verified) commented
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

There are actually a number of problems with that query and I'm not sure what options have been selected to cause them. Try creating the View again but building it step by step. If you find the step that makes the query go wrong, post it here.

dutchbob’s picture

dutchbob commented

See what you mean, the "rdf:type" was defined in a Filter. Seems a problem with cleaning up after removal. I will do as proposed and create one from scratch.

dutchbob’s picture

dutchbob commented 
<klex:instance_person_9483893> klex:hasOccupation <klex:instance_prof:111> .
<klex:instance_prof:111> rdfs:label """painter""" .

What I want to get out is a table showing:
URI (Person) || Profession (label)

Steps performed in Sparql Views Resource Types:
- Define URI as text field (URI)
- Define rdfs:label as text field (LABEL)
- Define klex:hasOccupation as RELATION type (Sparql related concept module) (hasOCC)

Then in Sparql views:
- define a new view, set up against SPARQL end point
- field URI is there as default
- add field LABEL
- add relation hasOCC as "Relationship"
- add this relation to "LABEL".

There must be a breach in my line of reasoning when I defined this, since the output in SPARQL preview looks like this(and woops, there the "dangling" variable pops up again):

PREFIX klex: <http://data.nasjonalmuseet.no/data/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT DISTINCT ?artist ?artist_field_proflabel
WHERE {
?artist klex:hasOccupation ?artist_field_proflrel2.
?artist_field_proflrel2.
 OPTIONAL {?artist_field_proflrel2 rdfs:label ?artist_field_proflabel}
 } 
LIMIT 25
Anonymous’s picture

Anonymous (not verified) commented

Can you try it without the OPTIONAL for the label and see if that is causing the problem? If so, then that would be a bug in SV.

dutchbob’s picture

dutchbob commented

Addition: I find this error when adding the relationship in the "advanced settings" of the VIEWS page.
User error: "." after subject found. in ARC2_SPARQLPlusParser in _sparql_request() (line 92 of /var/www/drupal/sites/all/modules/sparql/sparql.module).

dutchbob’s picture

dutchbob commented

#4: You're right. Switching to "REQUIRED" (remove "Optional" clause) makes the thing work. So the error seems to be in the generation of the Optional part of the query. Thanx for the tip!

Anonymous’s picture

Anonymous (not verified) commented
Title: Error in SPARQL Query generation » relationships break when using OPTIONAL
Category: support » bug
Status: Postponed (maintainer needs more info) » Active

Thank you for testing this and finding the issue, I'm marking it as a bug.

Unfortunately can't work on the module for the next 2-3 weeks, but this will be a priority once I get back to it.

dominikb1888’s picture

dominikb1888 commented

I can confirm the behavior in #6 based on the latest --dev.

stuartraetaylor’s picture

stuartraetaylor commented
Component: User interface » Code

I've run into this one too. Will see if I can come up with a patch for it.

stuartraetaylor’s picture

stuartraetaylor commented
Status: Active » Needs review
StatusFileSize
new 1273346-10-support-optional-relationships.patch5.96 KB

Here's the patch. I've had to change the way the WHERE clause is generated quite significantly so this patch would benefit from some more testing in case I've broken something :)



As far as I can tell, there's three main situations when combining relationships and optional.

1) The relationship is required AND the field using the relationship is required. The where clause should look something like this:

WHERE {
 ?subject ex:p1 ?subject_p1; ex:relationshipField ?subject_relationshipField.
 ?subject_relationshipField ex:p2 ?related_p2.
}

This works in the current version.

2) The relationship is required AND the field using the relationship is optional. The where clause should look something like this:

WHERE {
 ?subject ex:p1 ?subject_p1; ex:relationshipField ?subject_relationshipField.
 OPTIONAL { ?subject_relationshipField ex:p2 ?related_p2. }
}

There's a small bug in the current implementation that causes an error when the query is generated (the original problem in this issue).

3) The relationship is optional (not currently supported by SV), the field using the relationship is optional. The where clause should look something like this:

WHERE {
 ?subject ex:p1 ?subject_p1.
 OPTIONAL { 
   ?subject ex:relationshipField ?subject_relationshipField.
   OPTIONAL { ?subject_relationshipField ex:p2 ?related_p2. }
 }
}

This relies on nested optionals and isn't currently supported.

The patch supports (1), (2) and (3). I've updated the query generation part so that it first builds a data structure that gathers together the relationship triples, and the triples that use the relationship, then generates the SPARQL for the where clause. I'm not too familiar with the Views API so there may be an easier way to implement this - if there is please let me know!

stuartraetaylor’s picture

stuartraetaylor commented
StatusFileSize
new 1273346-10-support-optional-relationships.patch5.94 KB

Updated to remove a rogue DPM function call :)

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs review » Needs work

Thanks for posting this, I just started working on SV again, so just tested it. Unfortunately, the current patch gives some notices such as:

Warning: number_format() expects parameter 1 to be double, string given in number_field_formatter_view() (line 283 of /Users/clark/Sites/sparql-views/modules/field/modules/number/number.module).

Other than that, it seems to work just fine, though. I'll give more thorough review to the code and see if I can get the notices cleared up.

EDIT: Nevermind, this was caused by the issue I note in the next comment.

Anonymous’s picture

Anonymous (not verified) commented

Also, this will produce unexpected behavior for anything that currently has a relationship and doesn't have 'required' set because it relies on the "Require this relationship" option. This option should be changed to match the wording for fields.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs work » Fixed

Fixed with commit http://drupalcode.org/project/sparql_views.git/commit/b344766

Big thanks to Stuart for the great work! I made sure that the .git attribution was set to you, so you now have a commit on your drupal.org profile :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.