Constructing linked lists #349
justin2004
started this conversation in
General
Replies: 1 comment 5 replies
-
|
Hi,
Warning:I haven't tried this.
You can maybe add the following triple pattern to the where clause
?root ?nextslotp ?nextcoords . FILTER (?nextslotp=fx:next(?slotp))
This should guarantee that the next slot exists.
Il mar 21 mar 2023, 17:17 Justin Dowdy ***@***.***> ha
scritto:
… Say we have an input file of lat/lon pairs like this:
[
[
39.60016098620319,
-103.2195004094572
],
[
39.59573278327245,
-103.2194553002621
],
[
39.59523919837688,
-103.21904029566723
],
[
39.595260054147836,
-103.21651418074191
],
[
39.59563075964951,
-103.21613900415993
],
[
39.59672976424879,
-103.21604796697486
],
[
39.60046508037667,
-103.21688247450476
],
[
39.60065213316467,
-103.21905219408251
],
[
39.60064628777271,
-103.2190446076504
]
]
And we want to string them together into a linked list structure.
At the moment I have this query:
PREFIX fx: <http://sparql.xyz/facade-x/ns/>PREFIX ex: <http://example.com/>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX xyz: <http://sparql.xyz/facade-x/data/>PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>CONSTRUCT
{
ex:Coordinate-Area_0 rdf:type ex:Coordinate-Area .
ex:Coordinate-Area_0 ex:start ex:_Coordinates_1 .
ex:Coordinate-Area_0 rdfs:label "Some location" .
?slot_iri rdf:type ex:Coordinate-Part .
?slot_iri ex:lat ?lat .
?slot_iri ex:lon ?lon .
?slot_iri ex:next ?next_slot_iri .
} WHERE
{ SERVICE <x-sparql-anything:>
{ fx:properties
fx:location "/app/ll.json"
{ ?root rdf:type fx:root ;
?slotp ?coords .
?coords rdf:_1 ?lat ;
rdf:_2 ?lon
BIND(replace(str(?slotp), concat(str(rdf:), "_"), "") AS ?slot_num)
BIND(( xsd:int(?slot_num) + 1 ) AS ?next_slot_num)
BIND(IRI(concat(str(ex:), "_Coordinates_", ?slot_num)) AS ?slot_iri)
BIND(IRI(concat(str(ex:), "_Coordinates_", str(?next_slot_num))) AS ?next_slot_iri)
}
}
}
which produces these triples:
@Prefix ex: <http://example.com/> .@Prefix fx: <http://sparql.xyz/facade-x/ns/> .@Prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@Prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .@Prefix xsd: <http://www.w3.org/2001/XMLSchema#> .@Prefix xyz: <http://sparql.xyz/facade-x/data/> .
ex:_Coordinates_2 rdf:type ex:Coordinate-Part ;
ex:lat "39.59573278327245"^^xsd:double ;
ex:lon "-103.2194553002621"^^xsd:double ;
ex:next ex:_Coordinates_3 .
ex:_Coordinates_7 rdf:type ex:Coordinate-Part ;
ex:lat "39.60046508037667"^^xsd:double ;
ex:lon "-103.21688247450476"^^xsd:double ;
ex:next ex:_Coordinates_8 .
ex:Coordinate-Area_0 rdf:type ex:Coordinate-Area ;
rdfs:label "Some location" ;
ex:start ex:_Coordinates_1 .
ex:_Coordinates_5 rdf:type ex:Coordinate-Part ;
ex:lat "39.59563075964951"^^xsd:double ;
ex:lon "-103.21613900415993"^^xsd:double ;
ex:next ex:_Coordinates_6 .
ex:_Coordinates_3 rdf:type ex:Coordinate-Part ;
ex:lat "39.59523919837688"^^xsd:double ;
ex:lon "-103.21904029566723"^^xsd:double ;
ex:next ex:_Coordinates_4 .
ex:_Coordinates_8 rdf:type ex:Coordinate-Part ;
ex:lat "39.60065213316467"^^xsd:double ;
ex:lon "-103.21905219408251"^^xsd:double ;
ex:next ex:_Coordinates_9 .
ex:_Coordinates_1 rdf:type ex:Coordinate-Part ;
ex:lat "39.60016098620319"^^xsd:double ;
ex:lon "-103.2195004094572"^^xsd:double ;
ex:next ex:_Coordinates_2 .
ex:_Coordinates_6 rdf:type ex:Coordinate-Part ;
ex:lat "39.59672976424879"^^xsd:double ;
ex:lon "-103.21604796697486"^^xsd:double ;
ex:next ex:_Coordinates_7 .
ex:_Coordinates_4 rdf:type ex:Coordinate-Part ;
ex:lat "39.595260054147836"^^xsd:double ;
ex:lon "-103.21651418074191"^^xsd:double ;
ex:next ex:_Coordinates_5 .
ex:_Coordinates_9 rdf:type ex:Coordinate-Part ;
ex:lat "39.60064628777271"^^xsd:double ;
ex:lon "-103.2190446076504"^^xsd:double ;
ex:next ex:_Coordinates_10 .
Which is basically the desired output except for this single triple:
ex:_Coordinates_9 ex:next ex:_Coordinates_10 .
Anyone have an idea about how to prevent that triple from getting created?
It would be easy to fix in a post-processing step but I am curious if we
could prevent it from getting created in that single query.
—
Reply to this email directly, view it on GitHub
<#349>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZHIZJIBEVMBEROM7VTHQDW5HIBHANCNFSM6AAAAAAWCVPG7Y>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
5 replies
-
|
@luigi-asprino It worked! Clever. |
Beta Was this translation helpful? Give feedback.
-
|
@luigi-asprino Ah, I spoke a little soon. It looks like that causes it to not produce these triples: ex:_Coordinates_9 rdf:type ex:Coordinate-Part ;
ex:lat "39.60064628777271"^^xsd:double ;
ex:lon "-103.2190446076504"^^xsd:double .since it is the last in the chain |
Beta Was this translation helpful? Give feedback.
-
|
True.. well.. |
Beta Was this translation helpful? Give feedback.
-
Can't you wrap it in an OPTIONAL clause? (not tried) OPTIONAL { ?root ?nextslotp ?nextcoords . FILTER (?nextslotp=fx:next(?slotp)) } |
Beta Was this translation helpful? Give feedback.
-
|
ah, that union did it, @luigi-asprino . nice! |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Say we have an input file of lat/lon pairs like this:
[ [ 39.60016098620319, -103.2195004094572 ], [ 39.59573278327245, -103.2194553002621 ], [ 39.59523919837688, -103.21904029566723 ], [ 39.595260054147836, -103.21651418074191 ], [ 39.59563075964951, -103.21613900415993 ], [ 39.59672976424879, -103.21604796697486 ], [ 39.60046508037667, -103.21688247450476 ], [ 39.60065213316467, -103.21905219408251 ], [ 39.60064628777271, -103.2190446076504 ] ]And we want to string them together into a linked list structure.
At the moment I have this query:
which produces these triples:
Which is basically the desired output except for this single triple:
Anyone have an idea about how to prevent that triple from getting created? It would be easy to fix in a post-processing step but I am curious if we could prevent it from getting created in that single query.
Beta Was this translation helpful? Give feedback.
All reactions