Given that CONSTRUCT returns a *set of triples*, I doubt that the
ordering will be preserved. At least it doesn't has to be preserved
according to the SPARQL standard.

Indeed, you might get lucky but this is basically implementation specific

On 23.12.20 08:21, Martynas Jusevičius wrote:
> If ordering is required, you can use a sub-SELECT in CONSTRUCT:
>
> CONSTRUCT
> {
>     ?person :LastName ?LastName; :FirstName ?FirstName; :Address ?Address .
>     ?Address :Street ?Street; :City ?City; :State ?State; :Zip ?Zip
> }
> {
>     {
>         SELECT ?person ?LastName ?FirstName ?Street ?City ?State ?Zip
>         WHERE
>         {
>             ?person :LastName ?LastName; :FirstName ?FirstName;
> :Address ?Address .
>             ?Address :Street ?Street; :City ?City; :State ?State; :Zip ?Zip
>         }
>     }
>     ORDER BY ?LastName ?FirstName
> }
>
> On Tue, Dec 22, 2020 at 5:02 PM Erich Bremer <er...@ebremer.com> wrote:
>> The construct will give me the raw data, but the select will give me
>> distinct solutions (assuming I have DISTINCT specified) and even order them
>> for me in various ways. My use case would be a grid that when I want to
>> trigger an edit of a particular address displayed. If I could access the
>> triple pattern to that specific QuerySolution, I could then construct a
>> sparql update query to modify said entry as I could get the complete triple
>> associated with a particular city value.  I could include a variable in the
>> select for the address, however, then it leaves the coder to keep track of
>> what is what out of the variables. It doesn't seem like QuerySolution or
>> ResultSet exposes that information, but I would think that information is
>> buried somewhere below.  - Erich
>>
>> On Tue, Dec 22, 2020 at 9:19 AM Nouwt, B. (Barry)
>> <barry.no...@tno.nl.invalid> wrote:
>>
>>> I agree with Lorenz that you probably want to look at SPARQL CONSTRUCT and
>>> more specifically CONSTRUCT *WHERE* (
>>> https://www.w3.org/TR/sparql11-query/#constructWhere).
>>>
>>> Your query would become:
>>>
>>> CONSTRUCT WHERE {
>>>         ?person :LastName; :FirstName ?FirstName; :Address ?Address .
>>>         ?Address :Street ?Street; :City ?City; :State ?State; :Zip ?Zip
>>> }
>>>
>>> -----Original Message-----
>>> From: Lorenz Buehmann <buehm...@informatik.uni-leipzig.de>
>>> Sent: dinsdag 22 december 2020 14:49
>>> To: users@jena.apache.org
>>> Subject: Re: Returning a Triple from a QuerySolution for each Solution
>>> Variable
>>>
>>> Not sure if I understand your question, but should you just use SPARQL
>>> CONSTRUCT queries if you want to get triples?
>>>
>>> On 22.12.20 14:34, Erich Bremer wrote:
>>>> After executing a select statement like:
>>>>
>>>> select ?person ?LastName ?FirstName ?Street ?City ?State ?Zip where
>>>> {?person :LastName; :FirstName ?FirstName; :Address ?Address .
>>>>                      ?Address :Street ?Street; :City ?City; :State
>>>> ?State; :Zip ?Zip}
>>>>
>>>> and iterating through the ResultSet I can get (each person can have
>>>> multiple addresses linked via a blank node):
>>>> <person1> "Smith" "John" "3 RDF Road" "Semantic" "New York" "12345"
>>>> <person1> "Smith" "John" "22 Linked Lane" "Data City" "New York" "22113"
>>>>
>>>> Is there any way to get the underlying TriplePaths (defined in the
>>>> where clause of the Select) for each QuerySolution as I iterate
>>>> through the ResultSet, something like:
>>>>
>>>> qs.getTriple("City") ;
>>>>    <_:b1> :City "Semantic" .
>>>> qs = rs.next();
>>>> qs.getTriple("City");
>>>>    <_:b2> :City "Data City" .
>>>>
>>>> or possibly even iterators of Triples since each solution variable
>>>> could be part of multiple TriplePaths.
>>>>
>>>>   - Erich
>>>>
>>> This message may contain information that is not intended for you. If you
>>> are not the addressee or if this message was sent to you by mistake, you
>>> are requested to inform the sender and delete the message. TNO accepts no
>>> liability for the content of this e-mail, for the manner in which you use
>>> it and for damage of any kind resulting from the risks inherent to the
>>> electronic transmission of messages.
>>>

Reply via email to