True, but at least you get the right "window" of solutions, of which the triples are then unordered.
On Wed, Dec 23, 2020 at 9:16 AM Lorenz Buehmann <[email protected]> wrote: > > 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 <[email protected]> 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) > >> <[email protected]> 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 <[email protected]> > >>> Sent: dinsdag 22 december 2020 14:49 > >>> To: [email protected] > >>> 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. > >>>
