Re: Error initializing geosparql
I wasn't are of the geo:is3D property myself but is is apparently in Req 12 of the final GeoSPARQL release V1.0 https://portal.ogc.org/files/?artifact_id=44722 maybe it's only in the requirements. On Sun, Dec 12, 2021 at 8:24 PM Greg wrote: > Hi, > > The WKT parser supports XY, XYZ, XYM, and XYZM coordinate notations. The > presence of dimensions beyond XY should not have an impact on the > geomtery being used in spatial relation or other queries. The triples > exist in the graph and will be processed, but the GeoSPARQL 1.0 is 2D > only so the extra dimensions are not used in calculations. > > I'm not aware of an 'is3D' property in the v1.0 spec as this can be > tested using the 'geo:coordinateDimension' (either 2, 3, or 4 - i.e. XY, > XYZ, XYM and XYZM) and/or 'geo:spatialDimension' (either 2 or 3 - i.e. > XY and XYM or XYZ and XYZM) properties of geo:Geometry (Section 8.4). > These values are inferred in the Jena implementation and do not need to > asserted to be accessed. > > The standard also states that invalid geometry literals are to be > treated as errors, hence the 'DatatypeFormatException'. > > Thanks, > > Greg > > On 11/12/2021 19:33, Marco Neumann wrote: > > BTW this (the implementation of the property function) would be a great > > project for members in the community to make a contribution to the Jena > > project and the geosparql modul in particular. I would think that this > > could be a well manageable task for an experienced java developer with an > > interest in geospatial data processing. > > > > > > > > On Sat, Dec 11, 2021 at 6:19 PM Marco Neumann > > wrote: > > > >> That said, I am just looking at the code base and I think we are > missing a > >> property function for is3D which is mentioned in the v1.0 spec. > >> > >> On Sat, Dec 11, 2021 at 5:14 PM Marco Neumann > >> wrote: > >> > >>> good to see some discussion around this at GeoSPARQL 1.1. But from > what I > >>> can see it is still in an early phase with regards to 3D. > >>> > >>> The name geosparql++ was just used as a flag to indicate to the user > >>> that we are operating outside of the realm of OGC geosparql 1.0 spec. > >>> > >>> similar to what we do with sparql vs arq syntax > >>> > >>> > >>> > >>> On Sat, Dec 11, 2021 at 5:01 PM Lorenz Buehmann < > >>> buehm...@informatik.uni-leipzig.de> wrote: > >>> > It's on the way with GeoSPARQL 1.1, isn't it? At least there are > tickets > related to it, e.g. [1] and many functions will be stated to work on > 3D > as well [2] > > > I personally think we should go beyond GeoSPARQL soon with Jena to > provide > > users with more advanced features. Possibly flag it as geosparql++ or > the > > like. > You mean because there was already this GeoSPARQL+ thing from Steffen > Staab group with support for rasterized data? It's a shame that those > stuff does never make it into the main public projects they are based > on. What a waste of resources and time (from my point of view) > > [1] https://github.com/opengeospatial/ogc-geosparql/issues/238 > [2] > > > https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_b_1_functions_summary_table > > On 11.12.21 17:39, Marco Neumann wrote: > > That's correct Jean-Marc, no comma. > > > > And yes the OGC GeoSPARQL spec is not supporting 3D access methods. > And if > > you record a third dimension, which is of course possible, it will be > > ignored in Jena. Unfortunately the entire record will be. We could > record > > this as a bug but it's really not supported at the moment by the > spec. > Many > > of the spatial functions in the OGC GeoSPARQL spec operate with a 2D > > reference system. > > > > I personally think we should go beyond GeoSPARQL soon with Jena to > provide > > users with more advanced features. Possibly flag it as geosparql++ or > the > > like. > > > > Best, > > Marco > > > > > > > > > > On Sun, Dec 5, 2021 at 4:15 PM Jean-Marc Vanel < > jeanmarc.va...@gmail.com> > > wrote: > > > >> I fixed the WKT not having the right datatype, as said before; here > are the > >> SPARQL used to check and fix: > >> COUNT-spatial-wkt-as-string.rq > >> < > >> > > https://github.com/jmvanel/semantic_forms/blob/master/sparql/COUNT-spatial-wkt-as-string.rq > >> FIX-spatial-wkt-as-string.upd.rq > >> < > >> > > https://github.com/jmvanel/semantic_forms/blob/master/sparql/FIX-spatial-wkt-as-string.upd.rq > >> Now this is not the end of the road . Another imperfect data causing > >> geosparql initialization to fail : > >> > >> *Exception: Build WKT Geometry Exception - Type: point, Coordinates: > >> (2.353821,48.83399,0). Index 1 out of bounds for length 1* > >> 2021-12-05T15:48:54.166Z > [application-akka.actor.default-dispatcher-5] > >> ERROR
Re: Error initializing geosparql
Hi, The WKT parser supports XY, XYZ, XYM, and XYZM coordinate notations. The presence of dimensions beyond XY should not have an impact on the geomtery being used in spatial relation or other queries. The triples exist in the graph and will be processed, but the GeoSPARQL 1.0 is 2D only so the extra dimensions are not used in calculations. I'm not aware of an 'is3D' property in the v1.0 spec as this can be tested using the 'geo:coordinateDimension' (either 2, 3, or 4 - i.e. XY, XYZ, XYM and XYZM) and/or 'geo:spatialDimension' (either 2 or 3 - i.e. XY and XYM or XYZ and XYZM) properties of geo:Geometry (Section 8.4). These values are inferred in the Jena implementation and do not need to asserted to be accessed. The standard also states that invalid geometry literals are to be treated as errors, hence the 'DatatypeFormatException'. Thanks, Greg On 11/12/2021 19:33, Marco Neumann wrote: BTW this (the implementation of the property function) would be a great project for members in the community to make a contribution to the Jena project and the geosparql modul in particular. I would think that this could be a well manageable task for an experienced java developer with an interest in geospatial data processing. On Sat, Dec 11, 2021 at 6:19 PM Marco Neumann wrote: That said, I am just looking at the code base and I think we are missing a property function for is3D which is mentioned in the v1.0 spec. On Sat, Dec 11, 2021 at 5:14 PM Marco Neumann wrote: good to see some discussion around this at GeoSPARQL 1.1. But from what I can see it is still in an early phase with regards to 3D. The name geosparql++ was just used as a flag to indicate to the user that we are operating outside of the realm of OGC geosparql 1.0 spec. similar to what we do with sparql vs arq syntax On Sat, Dec 11, 2021 at 5:01 PM Lorenz Buehmann < buehm...@informatik.uni-leipzig.de> wrote: It's on the way with GeoSPARQL 1.1, isn't it? At least there are tickets related to it, e.g. [1] and many functions will be stated to work on 3D as well [2] I personally think we should go beyond GeoSPARQL soon with Jena to provide users with more advanced features. Possibly flag it as geosparql++ or the like. You mean because there was already this GeoSPARQL+ thing from Steffen Staab group with support for rasterized data? It's a shame that those stuff does never make it into the main public projects they are based on. What a waste of resources and time (from my point of view) [1] https://github.com/opengeospatial/ogc-geosparql/issues/238 [2] https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_b_1_functions_summary_table On 11.12.21 17:39, Marco Neumann wrote: That's correct Jean-Marc, no comma. And yes the OGC GeoSPARQL spec is not supporting 3D access methods. And if you record a third dimension, which is of course possible, it will be ignored in Jena. Unfortunately the entire record will be. We could record this as a bug but it's really not supported at the moment by the spec. Many of the spatial functions in the OGC GeoSPARQL spec operate with a 2D reference system. I personally think we should go beyond GeoSPARQL soon with Jena to provide users with more advanced features. Possibly flag it as geosparql++ or the like. Best, Marco On Sun, Dec 5, 2021 at 4:15 PM Jean-Marc Vanel < jeanmarc.va...@gmail.com> wrote: I fixed the WKT not having the right datatype, as said before; here are the SPARQL used to check and fix: COUNT-spatial-wkt-as-string.rq < https://github.com/jmvanel/semantic_forms/blob/master/sparql/COUNT-spatial-wkt-as-string.rq FIX-spatial-wkt-as-string.upd.rq < https://github.com/jmvanel/semantic_forms/blob/master/sparql/FIX-spatial-wkt-as-string.upd.rq Now this is not the end of the road . Another imperfect data causing geosparql initialization to fail : *Exception: Build WKT Geometry Exception - Type: point, Coordinates: (2.353821,48.83399,0). Index 1 out of bounds for length 1* 2021-12-05T15:48:54.166Z [application-akka.actor.default-dispatcher-5] ERROR jena - Exception class:class org.apache.jena.datatypes.DatatypeFormatException 2021-12-05T15:48:54.167Z [application-akka.actor.default-dispatcher-5] ERROR jena - Exception org.apache.jena.datatypes.DatatypeFormatException: Build WKT Geometry Exception - Type: point, Coordinates: (2.353821,48.83399,0). Index 1 out of bounds for length 1 org.apache.jena.geosparql.implementation.parsers.wkt.WKTReader.buildGeometry(WKTReader.java:141) org.apache.jena.geosparql.implementation.parsers.wkt.WKTReader.(WKTReader.java:50) org.apache.jena.geosparql.implementation.parsers.wkt.WKTReader.extract(WKTReader.java:292) org.apache.jena.geosparql.implementation.datatype.WKTDatatype.read(WKTDatatype.java:89) org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:69)
Re: How to cite Jena?
On 12/12/2021 06:19, Luis Enrique Ramos García wrote: Hi, I think this is the first paper of jena: https://dl.acm.org/doi/10.1145/1013367.1013381 there you can get the citation. Luis Ramos That only covers the API and it's implementation. (The SQL database mentioned is the "RDB" system that was dropped a long time ago.) It's also "pre Apache". It is good to recognize Brian McBride who started the project. Andy El sáb, 11 dic 2021 a las 15:36, Jakub Jałowiec (< j.jalow...@student.uw.edu.pl>) escribió: Hi, is there any preferred way to cite Apache Jena in a publication, preferably in BibTeX? Best regards, Jakub
Re: How to cite Jena?
On 11/12/2021 14:35, Jakub Jałowiec wrote: Hi, is there any preferred way to cite Apache Jena in a publication, preferably in BibTeX? Best regards, Jakub Hi Jakub, thank you for asking. You've done the right thing already. The name of the project is "Apache Jena". The first use in a paper, and use in a reference, should be that. Then "Jena" can be used. It's a trademark of the Apache Software Foundation [1]. This is also the industry practice. The reference should indicate the website https://jena.apache.org/. (https please!). If relevant to, say, reproducibility of results, it'll need to include the release version number. The date would be helpful to the reader. It is not "TDB" or "Fuseki" on their own. They are informal names to parts of the whole system. They also change over time and versions! You could say "Apache Jena Fuseki" for the triplestore but as the components function as part of the whole, "Apache Jena" would be accurate. Andy [1] https://www.apache.org/foundation/marks/#books
Re: Information about Apache Jena and Log4j2 vulnerability.
Please don't mix the focus of the thread. This thread is important information about the Apache Jena project. To be clear to the wider audience: RDF Delta is not under the governance of the Apache Jena PMC. Andy Obviously, the published mitigations work with the combined RDF Delta/Fuseki artifact. On 10/12/2021 19:05, Brandon Sara wrote: Andy, will you be releasing an RDF-Delta update that uses 4.3.1 soon as well?
Re: How to cite Jena?
it would remain for andy seaborne to clarify this, but google indicates two earlier papers by mcbride, one of which is cited by this acm paper: https://scholar.google.com/scholar?hl=en_sdt=0%2C5=jena+rdf= > On 2021-12-12, at 07:19:25, Luis Enrique Ramos García > wrote: > > Hi, > > I think this is the first paper of jena: > > https://dl.acm.org/doi/10.1145/1013367.1013381 > > there you can get the citation. > > > Luis Ramos > > > > El sáb, 11 dic 2021 a las 15:36, Jakub Jałowiec (< > j.jalow...@student.uw.edu.pl>) escribió: > >> Hi, >> is there any preferred way to cite Apache Jena in a publication, preferably >> in BibTeX? >> >> Best regards, >> Jakub >>
