GeoSPARQL 1.1 Function URIs do not resolve in vocprez

[situx]

The GeoSPARQL 1.1 functions which have been added to the OGC Naming Authority do not resolve in the vocprez system. Only parameters and GeoSPARQL 1.0 functions resolve.

Example: http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/function/geosparql/minZ

[ghobona]

Thanks @situx for spotting the issue.

The URI does not resolve because it was specified as all lowercase here.

When called in all lowercase it returns an error message that indicates that the record is in the database but there are some missing relations that are needed for vocprez to display the information.

I will update it on RAINBOW this coming week.

[situx]

Thanks @ghobona but we found that it in fact affects all functions defined in GeoSPARQL 1.1, the minZ was only one example out of many. Further examples: http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/function/geosparql/asGML http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/function/geosparql/asGeoJSON http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/function/geosparql/asWKT http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/function/geosparql/asKML

We think there might be a more general problem here.

[ghobona]

The reason for the error was because some RDF subjects were missing a skos:inScheme predicate linking them to the GeoSPARQL Functions Register.

Using this script, I identified the following Function URIs as returning a 500 status error (which is how we identify those that are missing an inScheme predicate). I added the inScheme predicate and they now resolve.

• http://www.opengis.net/def/function/geosparql/area
• http://www.opengis.net/def/function/geosparql/asDGGS
• http://www.opengis.net/def/function/geosparql/asGML
• http://www.opengis.net/def/function/geosparql/asGeoJSON
• http://www.opengis.net/def/function/geosparql/asKML
• http://www.opengis.net/def/function/geosparql/asWKT
• http://www.opengis.net/def/function/geosparql/boundingCircle
• http://www.opengis.net/def/function/geosparql/concaveHull
• http://www.opengis.net/def/function/geosparql/dimension
• http://www.opengis.net/def/function/geosparql/isEmpty
• http://www.opengis.net/def/function/geosparql/isSimple
• http://www.opengis.net/def/function/geosparql/length
• http://www.opengis.net/def/function/geosparql/maxx
• http://www.opengis.net/def/function/geosparql/maxy
• http://www.opengis.net/def/function/geosparql/maxz
• http://www.opengis.net/def/function/geosparql/minx
• http://www.opengis.net/def/function/geosparql/miny
• http://www.opengis.net/def/function/geosparql/minz
• http://www.opengis.net/def/function/geosparql/metricArea
• http://www.opengis.net/def/function/geosparql/metricBuffer
• http://www.opengis.net/def/function/geosparql/metricDistance
• http://www.opengis.net/def/function/geosparql/metricLength
• http://www.opengis.net/def/function/geosparql/metricPerimeter
• http://www.opengis.net/def/function/geosparql/perimeter
• http://www.opengis.net/def/function/geosparql/aggboundingBox
• http://www.opengis.net/def/function/geosparql/aggboundingCircle
• http://www.opengis.net/def/function/geosparql/geometryN
• http://www.opengis.net/def/function/geosparql/numGeometries
• http://www.opengis.net/def/function/geosparql/aggConcaveHull
• http://www.opengis.net/def/function/geosparql/aggUnion
• http://www.opengis.net/def/function/geosparql/centroid
• http://www.opengis.net/def/function/geosparql/transform

After adding the inScheme predicate, I re-ran the script and confirmed that none of them now returns a 500 status error.

[ghobona]

Note that the next step is to add them to the Alias register so that their https equivalent resolves too.

[ghobona]

I've created a ticket (https://github.com/opengeospatial/ogc-geosparql/issues/454) in the ogc-geosparql repository about the minx/minX case issue.

[situx]

Thanks @ghobona Should we add the skos:inScheme predicate to the funcsrules.ttl file moving forward or is that something that has to be added at the NA?

[ghobona]

@situx Please go ahead and add the skos:inScheme predicates.

I would suggest placing functions and rules in separate registers. Currently they are all merged in the same register, which breaks the principle of "separation of concerns".

Please also remember the convention that the URI of a Collection is the same as that of a ConceptScheme but with a slash at the end. For example:

ConceptScheme http://www.opengis.net/def/geotiff-tag

Collection http://www.opengis.net/def/geotiff-tag/

[ghobona]

@situx One more thing, the skos:Collection that represents the Functions register must have a skos:member predicate for each skos:Concept represents a function.

The same goes for the Rules register.

[ghobona]

@situx Are all the ttl files ready for re-uploading to RAINBOW?

[rob-metalinkage]

@avillar - please check that the automatic entailments are in place - but I think if multiple concept schemes in the same file then explicit skos:inScheme will be required. There may be a discrepancy between entailments performed on CMS ingest and direct git->repo deployment actions.

[situx]

@ghobona Yes, I believe we have made all required changes to the TTL files

[ghobona]

Thanks @situx . I'll start the re-upload tomorrow morning.

[ghobona]

I've re-uploaded the revised turtle files. The registers now look much better.

However, I found that some URIs return 400 and 500 statuses. It's a small number of URIs. They are listed here.

So I will work on these final steps tomorrow:

• [x] Fix the URIs that are returning 400 and 500 statuses
• [x] Create aliases for all URIs

[ghobona]

Finished re-uploading the files.

@situx Triples from the following files will need to be added to the geosparql turtle source files in the ogc-geosparql repo, so that they can persist into future updates.

Fix for status 400 and 500 code errors

Fix for specific predicates missing from seven concepts

[situx]

Thanks @ghobona One question though: You now added the input and output parameters from the functions with the inScheme property. Is that accurate? I thought only functions would be added to the Scheme. Is that correct?

[ghobona]

@situx Yes, the parameters were added to the functions register, since they are parameters of functions. We can remove them if you prefer. Please note however that removing them without assigning them to a register will result in status 400 errors.

If you would like to create a parameters register, please send @avillar the turtle files. I suggest creating a new GitHub Issue since the issue described in this one (i.e. function URIs not resolving) has been resolved.

[situx]

@ghobona I am currently not sure if we want to create a parameter register. I will discuss it in the next GeoSPARQL meeting next week

[situx]

We talked about it and we decided to:

• Create a parameter register under the URL: http://www.opengis.net/def/function_parameter/geosparql
• I will rename parameters to have more convenient labels, not only "geom1", "geom" a.s.o. and come back to you @ghobona about that