initial list of issues

[VladimirAlexiev]

@avillar @rob-metalinkage @peterrdf Here's an initial list of issues from about 20 min inspection of the example json/turtle.

Conventions:

• Change the checkbox state as we go through the bullets
• If you can edit this description, add eventual notes as sub-bullets
• For links to show as code snippets, you need to refer to the specific commit (eg blob/c46b466e036857a719f31ae47c4753637f9ca248 not blob/master).
  As https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet describes, you can copy this link by using ... > Copy permalink (don't copy from the address bar). Let's adopt this convention since it's very convenient to see the snippets

Issues:

• rename this repo from chek-profiles to perhaps CityRDF-examples. I don't think our project controller will look nicely at me working on some other project's repo/stuff. Also, I feel it's prestigious to work on an RDF/OWL rendition of CityGML, but not so on somebody else's project.
• The city:CityJson type is wrong, because the turtle result is NOT json. Maybe rename this type to CityGML or CityData?

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 23 in c46b466

  [] a city:CityJson ;

• #2
  but city:hasVertex is unordered in turtle

  chek-profiles/cityjson/twobuildings.city.ttl

  Lines 44 to 46 in c46b466

  	city:hasVertex [ city:x 19211 ;
  	city:y 19441 ;
  	city:z 0 ],

• Ontology terms are defined with relative URL in the context, resulting in local file: URLs in turtle:

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 34 in c46b466

  [ a <file:///home/alx5000/work/Proyectos/ogc/chek-profiles/Building> ;

• boundaries have a similar structure to vertices (list of numeric triples), but city:hasVertex vs city:boundaries have very different structure:
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 44 in c46b466

  city:hasVertex [ city:x 19211 ;

  vs
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 32 in c46b466

  city:boundaries ( ( ( 0 1 2 ) ) ( ( 3 4 5 ) ) ( ( 4 6 5 ) ) ( ( 2 7 6 ) ) ( ( 5 8 9 ) ) ( ( 0 2 4 ) ) ( ( 4 2 6 ) ) ( ( 5 6 8 ) ) ( ( 8 10 9 ) ) ( ( 11 12 13 ) ) ( ( 11 9 12 ) ) ( ( 12 10 14 ) ) ( ( 9 10 12 ) ) ( ( 15 5 11 ) ) ( ( 5 9 11 ) ) ( ( 16 3 17 ) ) ( ( 17 5 15 ) ) ( ( 3 5 17 ) ) ( ( 18 17 15 ) ) ( ( 16 19 20 ) ) ( ( 20 19 21 ) ) ( ( 21 19 7 ) ) ( ( 3 20 4 ) ) ( ( 21 7 2 ) ) ( ( 16 20 3 ) ) ( ( 22 2 1 ) ) ( ( 22 21 2 ) ) ( ( 23 1 0 ) ) ( ( 23 22 1 ) ) ( ( 23 4 20 ) ) ( ( 23 0 4 ) ) ( ( 19 24 6 ) ) ( ( 19 6 7 ) ) ( ( 24 25 8 ) ) ( ( 24 8 6 ) ) ( ( 25 10 8 ) ) ( ( 25 14 10 ) ) ( ( 26 27 28 ) ) ( ( 29 26 28 ) ) ( ( 30 26 29 ) ) ( ( 30 31 26 ) ) ( ( 32 13 12 ) ) ( ( 32 12 33 ) ) ( ( 34 32 33 ) ) ( ( 34 33 35 ) ) ( ( 36 37 38 ) ) ( ( 37 39 38 ) ) ( ( 40 41 42 ) ) ( ( 40 42 43 ) ) ( ( 44 40 43 ) ) ( ( 45 40 44 ) ) ( ( 45 44 46 ) ) ( ( 44 47 46 ) ) ( ( 36 46 47 ) ) ( ( 36 47 37 ) ) ( ( 18 35 17 ) ) ( ( 18 34 35 ) ) ( ( 48 49 50 ) ) ( ( 48 50 51 ) ) ( ( 41 51 42 ) ) ( ( 41 48 51 ) ) ( ( 52 27 53 ) ) ( ( 52 28 27 ) ) ( ( 54 31 30 ) ) ( ( 54 55 31 ) ) ( ( 56 52 53 ) ) ( ( 55 56 53 ) ) ( ( 54 56 55 ) ) ( ( 38 39 49 ) ) ( ( 39 50 49 ) ) ( ( 20 21 22 ) ) ( ( 23 20 22 ) ) ( ( 52 29 28 ) ) ( ( 56 29 52 ) ) ( ( 54 29 56 ) ) ( ( 54 30 29 ) ) ( ( 15 11 32 ) ) ( ( 18 15 34 ) ) ( ( 34 15 32 ) ) ( ( 32 11 13 ) ) ( ( 38 49 46 ) ) ( ( 45 46 41 ) ) ( ( 36 38 46 ) ) ( ( 45 41 40 ) ) ( ( 46 49 41 ) ) ( ( 41 49 48 ) ) ( ( 50 12 14 ) ) ( ( 39 12 50 ) ) ( ( 19 27 24 ) ) ( ( 53 27 19 ) ) ( ( 16 35 31 ) ) ( ( 31 37 44 ) ) ( ( 16 31 55 ) ) ( ( 27 43 51 ) ) ( ( 27 51 24 ) ) ( ( 35 37 31 ) ) ( ( 26 43 27 ) ) ( ( 31 44 26 ) ) ( ( 16 53 19 ) ) ( ( 26 44 43 ) ) ( ( 37 47 44 ) ) ( ( 16 55 53 ) ) ( ( 43 42 51 ) ) ( ( 50 14 25 ) ) ( ( 33 12 39 ) ) ( ( 35 33 37 ) ) ( ( 24 51 25 ) ) ( ( 16 17 35 ) ) ( ( 51 50 25 ) ) ( ( 37 33 39 ) ) ) ;

• city:hasVertex vs city:boundaries don't use a consistent naming convention (I prefer just vertex, boundary)
• city:lod "2" may be better rendered as a number (2 or even 2.0) so one can compare LODs numerically
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 33 in c46b466

  city:lod "2" ] ],

• city:hasTransform, city:translate are defined as xsd:float or double, leading to inexact numeric representation and scientific notation. Maybe better define as xsd:decimal?
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 41 in c46b466

  city:translate [ city:x 3.005782e+05 ;

• (cosmetic) Nested blank nodes are not formatted well: city:x doesn't start in the same position as city:y, city:z:
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Lines 24 to 29 in c46b466

  	city:geographicalExtent [ city:max [ city:x 3.006181e+05 ;
  	city:y 5.041289e+06 ;
  	city:z 2.945e+01 ] ;
  	city:min [ city:x 3.005782e+05 ;
  	city:y 5.041258e+06 ;
  	city:z 1.3688e+01 ] ] ;

• an important root object "Building_1" is missing from the turtle
  

  chek-profiles/cityjson/twobuildings.city.json

  Line 15 in c46b466

  "Building_1": {

[avillar]

@VladimirAlexiev, thanks for your thorough review. A few quick notes:

• The city:CityJson type is wrong

Yes, you're absolutely right.

• but city:hasVertex is unordered in turtle

This is only half-done. The idea is to assign blank node ids to the vertices and the use them as references in the boundaries; however, I got stuck due to the flexible nature of boundaries, which can have anywhere between 0 and... 5? levels of nesting, depending on the type of geometry.

In any case, is the order of the vertices relevant (I'm honestly asking, since I'm not a CityJSON guru by any means)? Unless I'm mistaken, the order of the vertices is only important to the extent that the references in other constructs (e.g. boundaries) are consistent. In this example (bear with me for a second and imagine that the boundaries arrays and untangled), the boundaries would use blank node ids to refer to the specific vertices (to which rdflib would assign, in turn, blank node ids, instead of leaving them unlabeled as they are right now).

A RDF -> CityJSON converter could then just revert the process by defining an order (lexicographically?) to sort the vertices, mapping them to their position in the vertices array and replacing the references (e.g. boundaries) with the corresponding indexes.

Ontology terms are defined with relative URL in the context, resulting in local file: URLs in turtle

This is a bug in the pyld module (it's not expanding the terms as it should). I have pushed a workaround for this, so (fingers crossed) no more file:// URIs.

boundaries have a similar structure to vertices (list of numeric triples), but city:hasVertex vs city:boundaries have very different structure

Explained above.

city:hasVertex vs city:boundaries don't use a consistent naming convention

Agreed.

city:lod "2" may be better rendered as a number

Fixed by setting the @type.

city:hasTransform, city:translate are defined as xsd:float or double

Added the necessary @type's for rdflib to serialize it as xsd:decimal.

Nested blank nodes are not formatted well

This is just how rdflib serializes Turtle...

an important root object "Building_1" is missing from the turtle

The identifiers for the objects are used to generate the blank node ids; if you look at the ttl file, you'll see two different city objects ([1], [2]).

Of course, that should also be done for the parents and children as well, but as I said, this is all still far from complete.

[VladimirAlexiev]

@avillar Can you please open a new issue "how to represent geometry (vertices and indexes)"? It's crucial for the whole effort.
Please add this info:

• my concerns above
• your replies above
• info from your email

these extra considerations:

• JSONLD 1.0 didn't handle nested lists, but JSONLD 1.1 handles them
• maybe this is resolved in the GeoJson community? Google "geojson to jsonld" brings some hits, but I think they are old
• handling lists in RDF is indeed cumbersome
  • you can get all list members with rdf:rest*/rdf:first but there's no guarantee they will be in order
  • handling nested lists will be VERY cumbersome
• I think the right approach is to keep geometry as opaque literals (as in GeoSPARQL) and let a special index take care of them
  • but what are the operations mandated on CityGML geometries? Are they somewhere in the spec, or in a related OGC spec?
• The LBD community has no less than 5 ontologies for geometry: to capture it as triples, to describe various alternatives of where it is stored, etc.
• this shared library https://www.zotero.org/groups/3007408/semantic_bim/collections/82VA2WE2 has 21 papers on the topic (and I'd appreciate if you join that zotero group!), I should have all of them.
• I think this is the paper to read https://www.zotero.org/groups/3007408/semantic_bim/collections/82VA2WE2/items/Q6DQ5WCA/item-list Representing construction-related geometry in a semantic web context: A review of approaches. 10.1016/j.autcon.2020.103130

@rob-metalinkage and @peterrdf What's your take on geometry?

---

identifiers for the objects are used to generate the blank node ids;

Ah, but they should be used to make URLs (and perhaps emitted in a separate field identifier), not merely to distinguish the blank nodes.

[avillar]

Quick note: the nested lists issue was not really a JSON-LD 1.0 vs 1.1, but a problem with the rdflib JSON-LD parser...