Table of Contents

• Intro
• Input File
• ChatGPT 4o Results
  • 1. Syntax Issues (Turtle/RDF)
  • 2. Literal Datatypes & Language Tags
  • 3. CIM Modeling Issues
  • 4. Incorrect GeoJSON Vocabulary Use
  • 5. CIM Logical Modeling
  • 6. Unusual nesting of multiple language tags on same property
  • 7. Schema Conformance Checks (not errors, but flags)
  • Summary of Errors & Fixes
• ChatGPT 4.1 Results
  • 1. Syntax Error: Unusual Block Braces
  • 2. Invalid Use of Language Tags on Data Properties
  • 3. Data Type Mismatch
  • 4. GeoJSON Geometry: Coordinates Format
  • 5. Ambiguous or Non-standard Use of Blank Nodes
  • 6. Incorrect/Redundant Use of Language Tags on Method
  • 7. Potential Modeling Issues with geojson:properties
  • 8. Other Minor Issues & Best Practices
  • Summary Table of Issues
  • What To Do Next
• ChatGPT 4.5 Results
  • 1. Incorrect Use of Curly Braces { }
  • 2. Incorrect Datatype for dcterms:issued
  • 3. Missing rdf:type Declarations (a keyword)
  • 4. GeoJSON Polygon Syntax Issue
  • 5. Incorrect Linking of GeoJSON Properties
  • Summary of Errors:
• Human Findings
• Conclusions

While working on the Dataset Telemark-120 dataset I posted a number of issues to that project, and an internal task to convert GeoJSON representation to GeoSPARQL WKT.

Then I decided to see what advice ChatGPT can provide. I converted Telemark-120-WattApp-GL.geojson (which is also JSON-LD) Turtle, then added a named graph and saved as Trig, and asked GPT:

Q: What errors can you find in this electrical CIM data

I tried 3 ChatGPT versions, as listed in 3 sections below. comment on their findings using the **Comment:** tag.

Interestingly, each GPT version formatted its findings differently. I removed these differences from the document for uniformity:

• GPT 4o: numbered nested list and Unicode emojis:

## ✅ **1. Syntax Issues (Turtle/RDF)**
### ❌ Use of `{}` instead of a named graph or RDF collection

• GPT 4.1: numbered flat list, only text is bolded

##  1. **Syntax Error: Unusual Block Braces**

• GPT 4.5: numbered flat list, all of the heading is bolded

## **1. Incorrect Use of Curly Braces `{ }`**

I also added a section with my own findings.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix cim: <https://cim.ucaiug.io/ns#> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix geojson: <https://purl.org/geojson/vocab#> .
@prefix nc: <https://cim4.eu/ns/nc#> .
@prefix prov: <http://www.w3.org/ns/prov#> .

<http://publications.europa.eu/resource/authority/access-right/PUBLIC> dcterms:title "PUBLIC" .

<https://creativecommons.org/licenses/by-nc-sa/4.0/> dcterms:title "CC BY-NC-SA 4.0" .

<urn:uuid:bd53cf0a-2e2f-4230-a591-0233290b5f9b> dcterms:title "DIGIN" .

<urn:uuid:971c4254-5365-4aaf-8fa6-02658b3f8e05> {
  <urn:uuid:971c4254-5365-4aaf-8fa6-02658b3f8e05> a dcat:Dataset, geojson:FeatureCollection ;
    dcterms:description "Geospartial GridCapacity MAS1"@en ;
    dcterms:description "Stedsdata Nettkapasitet MAS1"@no ;
    dcat:isVersionOf <https://digin.no/Foundation/DIGIN10-30-WattApp_GL> ;
    dcat:keyword "GL" ;
    dcterms:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> ;
    dcterms:conformsTo <http://digin.no/ns/CIM/GeoJSON/1.0> ;
    dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:date ;
    dcterms:license <https://creativecommons.org/licenses/by-nc-sa/4.0/> ;
    dcterms:publisher <urn:uuid:bd53cf0a-2e2f-4230-a591-0233290b5f9b> ;
    dcterms:rights "© 2023 Copyright" ;
    dcterms:rightsHolder "DIGIN" ;
    dcterms:spatial <https://diginenergi.no/DIGIN10/WattApp> ;
    dcterms:temporal [
      a dcterms:PeriodOfTime ;
      dcat:startDate "2022-03-30T23:00:00Z"^^xsd:dateTime ;
    ] ;
    dcterms:title "DIGIN10-30-WattApp-GL" ;
    geojson:features <urn:uuid:58aee5a8-0cd9-467e-b5e7-180ac161d9b8> ;
    prov:generatedAtTime "2023-02-20T16:04:23Z"^^xsd:dateTime .

  <urn:uuid:4e51e598-8948-4c85-b151-f44ffddc5545> a cim:Feeder ;
    cim:IdentifiedObject.description "Sandefjord business and industry area"@en ;
    cim:IdentifiedObject.description "Sandefjord næring og industri område"@no ;
    cim:IdentifiedObject.mRID "urn:uuid:4e51e598-8948-4c85-b151-f44ffddc5545" ;
    cim:IdentifiedObject.name "Sandefjord_business_and_industry_area"@en ;
    cim:IdentifiedObject.name "Sandefjord_næring_og_industri_område"@no ;
    nc:Feeder.CapacitySchedule [
      nc:BaseTimeSeries.generatedAtTime "2022-11-07T12:05:43.641Z" ;
      nc:BaseTimeSeries.interpolationKind nc:TimeSeriesInterpolationKind.previous ;
      nc:BaseTimeSeries.kind nc:BaseTimeSeriesKind.forecast ;
      nc:BaseTimeSeries.method "KraftSystemUtredning"@no ;
      nc:BaseTimeSeries.method "Power System Report"@en ;
      nc:BaseTimeSeries.percentile "50" ;
      nc:CapacitySchedule.CapacityTimePoint [
        nc:CapacityTimePoint.atTime "2028-01-01T23:00:00.000Z" ;
        nc:CapacityTimePoint.maxAllocatedP [
          cim:ActivePower.value 0 ;
        ] ;
        nc:CapacityTimePoint.maxAllocatedQ [
          cim:ReactivePower.value 0 ;
        ] ;
        nc:CapacityTimePoint.maxP [
          cim:ActivePower.value 40 ;
        ] ;
        nc:CapacityTimePoint.maxQ [
          cim:ReactivePower.value 0 ;
        ] ;
        nc:CapacityTimePoint.minAllocatedP [
          cim:ActivePower.value 0 ;
        ] ;
        nc:CapacityTimePoint.minAllocatedQ [
          cim:ReactivePower.value 0 ;
        ] ;
        nc:CapacityTimePoint.minP [
          cim:ActivePower.value 0 ;
        ] ;
        nc:CapacityTimePoint.minQ [
          cim:ReactivePower.value 0 ;
        ] ;
      ] ;
      nc:IdentifiedObject.description "Det er i dag liten kapasitet til ny næring.."@no ;
      nc:IdentifiedObject.description "There is currently little capacity for new business.."@en ;
      nc:IdentifiedObject.name "Sandefjord, increased capacity for business and industry"@en ;
      nc:IdentifiedObject.name "Sandefjord, økt kapasitet til næring og industri"@no ;
    ] .

  <urn:uuid:58aee5a8-0cd9-467e-b5e7-180ac161d9b8> a geojson:Feature ;
    geojson:geometry [
      a geojson:Polygon ;
      geojson:coordinates ( ( ( 1.0229E1 5.9247E1 ) ( 1.0184E1 5.92E1 ) ( 1.0143E1 5.9139E1 ) ( 
        1.0202E1 5.9138E1 ) ( 1.0276E1 5.9161E1 ) ( 1.0311E1 5.9229E1 ) ( 1.0229E1 5.9247E1 ) ) ) ;
    ] ;
    geojson:properties <urn:uuid:4e51e598-8948-4c85-b151-f44ffddc5545> .

}

This RDF/Turtle document for CIM data contains a number of potential syntax and semantic issues. Here's a breakdown of problems categorized as syntax, RDF modeling, CIM compliance, and GeoJSON misuse:

Use of {} instead of a named graph or RDF collection

This block is not valid Turtle:

<urn:uuid:971c4254-5365-4aaf-8fa6-02658b3f8e05> {
  ...
}

Explanation: Turtle does not support { ... } after a subject IRI like this. This syntax is invalid unless you’re using TriG (for named graphs), in which case it must be declared as TriG and enclosed in a named graph context:

Fix: If you intended a named graph, declare it in TriG or restructure it using triples.

Comment: Right! (I was negligent and marked the code block as ttl instead of trig). But it's unclear what it means by "enclosed in a named graph context".

dcterms:issued uses xsd:date, but the value includes time:

dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:date ;

Explanation: xsd:date is for dates only (e.g., 2023-02-21). The correct datatype for this value is xsd:dateTime.

Fix:

dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:dateTime ;

Comment: Right! Previously reported CIM4NoUtility#361 as JSON-LD dct:issued: wrong datatype

Use of @no and @en on the same property multiple times:

cim:IdentifiedObject.description "..."@en ;
cim:IdentifiedObject.description "..."@no ;

Explanation: RDF allows this, but some parsers might overwrite one value. It's better practice to use separate blank nodes for multi-lingual values when further metadata might be needed.

Comment: Wrong. RDF props can natively carry multiple values, and a parser is not allowed "to overwrite" a value. The advice to use blank nodes is nonsense.

geojson:coordinates uses parentheses (), not RDF lists ([])

geojson:coordinates ( ( ( 1.0229E1 5.9247E1 ) ... ) ) ;

Explanation: RDF lists are not syntactically valid GeoJSON encoding. You should serialize coordinates as a string or JSON-like RDF representation.

Fix (suggested):

geojson:coordinates "[[[10.229, 59.247], [10.184, 59.2], ...]]" ;

Or represent as an RDF structure using blank nodes.

Comment: JSON-LD 1.1 was adapted to allow nested lists, precisely to be able to carry geojson coordinates. So the above RDF list is correct (also notice that GPT mistakenly cites () vs []).

However, geojson in RDF list representation is not supported by GeoSPARQL engines. Using JSON-like string is fine for transferring the coordinates, but again not for indexing by GeoSPARQL engine. Previously I posted CIM4NoUtility#337 use geo:asGeoJSON instead of (or in addition to) GeoJSON-LD, and an internal task to restructure to GeoSPARQL WKT according to this spec.

cim:ActivePower.value 40 lacks unit:

CIM standard requires that ActivePower and ReactivePower values specify units (e.g., MW, kW).

Fix (suggested RDF structure):

nc:CapacityTimePoint.maxP [ a cim:ActivePower ;
  cim:ActivePower.value 40 ;
  cim:ActivePower.unit cim:UnitSymbol.MW ;
]

Comment: On the surface, this is correct. But there is a deeper story:

• cim:ActivePower is declared a class, whereas props that point to it are declared owl:DatatypeProperty
• Actual CIM instance data never carries value and unit, instead the quantityKind (cim:ActivePower) and unit (cim:UnitSymbol.MW) are added as annotations on the data prop.

The project Inst4CIM-KG describes numerous improvements to CIM ontologies (RDFS), instance data (RDF) and shapes (SHACL), including QuantityKinds and Units of Measure, and specifically Fixed Units Representation.

So a better suggestion is this:

nc:CapacityTimePoint.maxP "40"^^xsd:float ;

Previously reported as CIM4NoUtility#364 parasitic blank nodes with attributes like cim:ReactivePower.value, cim:ActivePower.value

You’re doing this:

nc:BaseTimeSeries.method "Power System Report"@en ;
nc:BaseTimeSeries.method "KraftSystemUtredning"@no ;

While this is valid RDF, CIM models normally treat method names as objects or instances, not as simple literals. It may be worth revisiting the class/instance modeling here depending on your ontology.

Comment: If method will be used for lookup then indeed it's better to have only one value that is xsd:string not rdf:langString. The same RDF prop can easily carry multiple values, but such variety of values will make queries less uniform.

It's hard to assess the claim that "CIM models normally...": the model cim4.no GridCapacity/AbstractClasses/BaseTimeSeries doesn't list method, but lists actionMethod as string.

However, it is better to use CIM Enumeration classes (akin to skos:Concept) to represent lookup values as resources, and to add as many multilingual labels (akin to skos:prefLabel) as needed.

• Previously reported Inst4CIM-KG#170 measurementType, MeasurementValueSource structure (feature of interest, qualifier)

  measurementType is one of the very few enums in CIM that is not a resource but a string.

• Now expanded on this thought by reporting CIM4NoUtility#381 Enumeration Strings that are candidates to be converted to Things (Enumeration values)

• geojson:features should point to a collection of geojson:Feature objects. Currently, it’s a single value.

  • Comment: This is nonsense. A single feature is ok

• nc:CapacityTimePoint.atTime has correct format, but confirm whether your schema wants it to be a typed literal or a CIM object.

  • Comment: Inst4CIM-KG Add Datatypes To Instance Data describes how CIM instance data lacks datatypes, and has a script fix-datatypes-new.ru to add datatypes from the ontology. However, we don't have the ontology that defines the above property (in fact 9 nc:CapacityTimePoint attributes lack definition)

If you'd like, I can help rewrite the fixed version in valid Turtle or TriG. Let me know.

Certainly! Here is a detailed analysis of the Turtle (TTL) RDF data you posted, focusing on syntactic, semantic, and modeling issues according to standard RDF, DCAT, GeoJSON, and CIM usage:

Issue: This line opens a block using curly braces {:

<urn:uuid:971c4254-5365-4aaf-8fa6-02658b3f8e05> {

Problem:

• Turtle syntax does not allow grouping triples in curly braces ({ ... }) after a subject IRI.
• All triples must be standalone or use [] for blank nodes.
• Curly braces here are invalid and will cause any standards-compliant parser to fail.

Fix: Remove the curly braces and write each triple separately.

Comment: This is valid Trig syntax, but 4.1 didn't recognize it as such. It's my fault that I gave the lag tag ttl rather than trig.

Example:

cim:IdentifiedObject.name "Sandefjord_business_and_industry_area"@en ;
cim:IdentifiedObject.name "Sandefjord_næring_og_industri_område"@no ;

• This is valid in Turtle and RDF for plain string literals with language tags, but you have used underscores (_) in what appears to be a technical identifier. Usually, @en would be for a human-readable label, not an internal name.

Suggestion:

• If name is for display, this is fine. If it's a technical identifier, don't use language tags; use one xsd:string literal without a tag.

Comment: This is a good suggestion: spaces should be used instead of underscores.

Example:

dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:date ;

• "2023-02-21T08:08:00.000Z" is an xsd:dateTime (has time), not an xsd:date (just YYYY-MM-DD).

Fix:

dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:dateTime ;

or

dcterms:issued "2023-02-21"^^xsd:date ;

• Pick the type that matches the value.

Comment: Both suggestions are right.

Example:

geojson:coordinates ( ( ( 1.0229E1 5.9247E1 ) ... ) ) ;

• This attempts to encode a nested array as a Turtle list. However, GeoJSON geometry in RDF is usually modeled with a JSON literal, or as a plain string, not as nested Turtle lists.

Problem:

• Most GeoJSON RDF vocabularies expect a single JSON literal as the value of geojson:coordinates, not a deeply nested RDF collection.
• Turtle lists are not equivalent to JSON arrays in most RDF tools.

Fix:

• Use a literal value or use a proper GeoSPARQL geometry representation if spatial interoperability is required.

Comment: Right! I've argued several times with the electrical engineering community to use GeoSPARQL with specific geometry representations (asWKT, asGML, asGeoJSON) rather than GeoJSON as nested lists. Dataset Telemark-120#GeoJson Data shows a model how to convert GeoJSON to GeoSPARQL.

Example:

dcterms:temporal [
  a dcterms:PeriodOfTime ;
  dcat:startDate "2022-03-30T23:00:00Z"^^xsd:dateTime ;
] ;

• This is valid, but make sure your consuming tools support blank nodes.
  • Comment: This is a matter of taste
• Also, note that DCAT 3 encourages the use of time:TemporalEntity instead.
  • Comment: This is false, as you can see at temporal coverage.
    • time:TemporalEntity is only discussed in the context of hasBeginning
    • This is only needed for geological and archeological periods, and even in such case you don't need to use time:TemporalEntity

Example:

nc:BaseTimeSeries.method "KraftSystemUtredning"@no ;
nc:BaseTimeSeries.method "Power System Report"@en ;

• If this property is not defined as multi-lingual, you may want to use a single value, or use something like rdfs:label for multilingual strings.

Comment: As already discussed above, it's better to use Enumeration Classes

Example:

geojson:properties <urn:uuid:4e51e598-8948-4c85-b151-f44ffddc5545> .

• In GeoJSON RDF vocabularies, geojson:properties is sometimes expected to be a blank node containing key/value pairs, not a link to another resource. However, this depends on the vocabulary you are using.

Suggestion: Check the vocabulary documentation; you may need to embed a blank node here, or at least clarify your modeling intent.

Comment: Whether a node has a URI or is blank, does not change the modeling pattern. Although it's a bit unusual to point to a Power System Resource node, it is valid modeling.

• Your use of both dcterms:title and dcat:keyword is good, but make sure your toolchain expects them both.
  • Comment: The two have completely different purpose, so the advice is not meaningful
• Double-check that all UUID URIs resolve or are unique within your dataset.
  • Comment: UUID URIs cannot possibly resolve. And how to check "uniqueness" of URIs? RDF knowledge graphs consist of triples: nodes/URIs are not "declared" separately.

• Remove the curly braces and flatten the triples.
• Correct datatype mismatches (xsd:date vs xsd:dateTime).
• Reconsider how you serialize geojson:coordinates.
• Check the use of geojson:properties against your chosen vocabulary.
• Validate your data using an RDF validator (W3C RDF Validator or RDF Triple Checker) for syntax and semantic errors.
• Align modeling with DCAT and GeoJSON RDF best practices.

Would you like a corrected version of this data, or help with a validator output?

The provided CIM RDF data contains several issues:

• Curly braces ({}) are not valid syntax in RDF/Turtle to group triples arbitrarily. They are used specifically for named graphs in TriG syntax, but here no named graph keyword (e.g., GRAPH) is used. This seems like a mix-up between Turtle and TriG formats.
• Correction: Either remove the curly braces completely (making it standard Turtle), or clearly indicate it's TriG syntax by defining a named graph properly using a graph keyword.
• Comment: The GRAPH keyword is optional, so this is valid TriG. It's not a mix-up between Turtle and TriG, because TriG is a superset of Turtle.

Example Correction (if intended as Turtle, remove braces entirely):

urn:uuid:971c4254-5365-4aaf-8fa6-02658b3f8e05 a dcat:Dataset, geojson:FeatureCollection ;
...

• Currently:

  dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:date ;

• Error: The literal is actually a dateTime, not a date.

• Correction:

  dcterms:issued "2023-02-21T08:08:00.000Z"^^xsd:dateTime ;

Comment: Right!

• Inner blank nodes such as CapacitySchedule and CapacityTimePoint do not declare their RDF type explicitly.

• For example:

  nc:Feeder.CapacitySchedule [
      # Missing type declaration here (e.g., `a nc:CapacitySchedule;`)
      nc:BaseTimeSeries.generatedAtTime "2022-11-07T12:05:43.641Z" ;
      ...
  ] ;

• Correction: Add explicit type declarations.

  nc:Feeder.CapacitySchedule [
      a nc:CapacitySchedule ;
      ...
  ] ;

Comment: Correct. However, more props are needed.

• The polygon coordinates are expressed with parentheses (( )), which is not valid in standard Turtle syntax for lists. Turtle requires RDF Collections (rdf:List) or blank-node-based lists.

• Current issue:

  geojson:coordinates ( ( ( 1.0229E1 5.9247E1 ) ... ) ) ;

• Correction: Use RDF lists explicitly or JSON literal strings, typically GeoJSON coordinates are encoded as literals:

  geojson:coordinates "[[[10.229,59.247],[10.184,59.20],...]]"^^geojson:coordinates ;

• or use proper RDF list structures:

  geojson:coordinates (
    ( ( 10.229 59.247 ) ( 10.184 59.20 ) ... )
  ) ;

  (assuming the ontology explicitly supports this RDF Collection format.)

Comment: (...) is valid Turtle shortcut to express a List. In fact the last suggested correction repeats the original data ;-)

• We already discussed that instead of nested lists, it's beter to use GeoSPARQL representation.

• Currently:

  geojson:properties <urn:uuid:4e51e598-8948-4c85-b151-f44ffddc5545> .

• geojson:properties usually expects a structured set of property key-value pairs (like a blank node or dictionary), not a single IRI.

• Correction: If you intend to link to another feature/object, consider using a different property explicitly designed for linking:

  geojson:properties [
    cim:relatedFeeder <urn:uuid:4e51e598-8948-4c85-b151-f44ffddc5545>
  ] ;

  or, define explicitly according to your ontology.

Comment: RDF is a graph and blank nodes don't change the modeling pattern. So it is correct for geojson:properties to link to a Power System Resource node with its own props.

• Misuse of curly braces {} (Syntax error)
• Wrong datatype (date vs. dateTime)
• Missing explicit rdf:type declarations for blank nodes
• GeoJSON polygon coordinates improperly formatted
• Misused geojson:properties property

Resolving these will lead to valid, standards-compliant RDF data.

I must say that I had already found and reported nearly all problems before I tried ChatGPT.

• I posted a new issue based on GPT's suggestion in 6. Unusual nesting of multiple language tags on same property

But none of the GPT versions found these additional problems:

• nc:Feeder.CapacitySchedule and nc:CapacitySchedule.CapacityTimePoint should have URNs and key props like cim:IdentifiedObject.mRID (in addition to rdf:type that ChatGPT 4.5 reported)
• Coordinates like ( 1.0229E1 5.9247E1 ) are truncated from their original precision, and the scientific notation (using exponent) may throw off some geo-processing software.
• nc:BaseTimeSeries.generatedAtTime should have a datatype
• A number of other problems reported in [Telemark-120 Errors](Telemark-120 Errors), which is part of the deeper analysis Dataset Telemark-120.

Between the different versions tried above, ChatGPT does a reasonably good job at spotting problems.

• However, it also makes a number of bad or imprecise suggestions (its precision is not perfect).
  • Worse, many of its bad advice is cast as reasonably-sounding and authoritative, eg

    Double-check that all UUID URIs resolve or are unique

  • Some diagnostics are correct (eg that <urn> {...} is only allowed in TriG), but the explanations/suggestions are muddled or wrong (adding the GRAPH keyword is unnecessary)
• As for recall, it missed some simple issues as listed in the previous section. For a really in-depth analysis, one would need a much longer interaction session to explore various issues and sub-issues.

In conclusion: ChatGPT is an able assistant that can help a Knowledge Graph (KG) engineer with spotting errors. However, it is no substitute for knowledge and experience, and can easily mislead a novice KG into wrong conclusions.