Good practice for publishing geometry of a thing as different geometry types?

Hello all,

This question is similar to an earlier question I asked and for which a
somewhat workable solution was found: Good practice for RDF publishing of
multiple geometries with different CRSs?
<https://lists.w3.org/Archives/Public/public-sdw-wg/2016Apr/0030.html>

As part of the same use case, I now want to publish two kinds of geometry
for a building: the centroid (a 2D point) and the shape at ground level (a
2D polygon). I could just publish both the geometries, but the question is
how a consumer can select only the points or only the polygons.

Up till now, I have been using GeoSPARQL WKT to express geometry. But part
of the WKT specification is that the geometry type (e.g. POINT or POLYGON)
is part of the WKT string. That makes it difficult to use as a selection
criterion.

A solution for publishing multiple geometries that differ in CRS was
workable because a vocabulary exists for specifying a CRS:
http://data.ign.fr/def/geometrie, provided by IGN France.

Fortunately, the same vocabulary can be used to specify geometry. For
example:

ex:location1234
   a dcterms:Location ;
   locn:geometry ex:geom1234 ;
   locn:geometry ex:geom6789 .

ex:geom1234
   a geom:Geometry, geom:Point ;
   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
   gsp:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
POINT(...)"^^geosparql:wktLiteral .

ex:geom6789
   a geom:Geometry, geom:Polygon ;
   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
   gsp:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
POLYGON(...)"^^geosparql:wktLiteral .

When published like this, a consumer could easily ask for only the points
(instances of class geom:Point) or only the polygons.

But there is a problem with this approach: like the CRS, the geometry type
is specified twice: next to the coordinate expression and within the
coordinate expression. The specifications of geometry type and CRS are
redundant, which has drawbacks of data bloat and risk of inconsistency. But
perhaps it is still the best available solution at the moment? Can this
approach be recommended as a best practice?

Regards,
Frans