Error when parsing valid shacl/ttl file

[james-martin-jd]

Recently a specific file on my Solid Pod began throwing errors. The file in question is here, but others were able to replicate the problem with the same file contents as evidenced here.

The error is strange because the source view is fine, and I can edit and save and it validates as valid ttl. But the data view is throwing errors. In the console I see: setCredentials: https://jmartin.inrupt.net/public/shapes/book-shacl.ttl starts as: undefined and a larger error is displayed on the screen:

Error: Unhandled node type: undefined
  undefined
    Error: Unhandled node type: undefined  undefined
        at m (https://jmartin.inrupt.net/mashlib.min.js:27:330581)  undefined
        at m (https://jmartin.inrupt.net/mashlib.min.js:27:330386)  undefined
        at h (https://jmartin.inrupt.net/mashlib.min.js:27:329136)  undefined
        at m (https://jmartin.inrupt.net/mashlib.min.js:27:330021)  undefined
        at h (https://jmartin.inrupt.net/mashlib.min.js:27:329136)  undefined
        at Object.statementsAsTables (https://jmartin.inrupt.net/mashlib.min.js:27:331015)  undefined
        at https://jmartin.inrupt.net/mashlib.min.js:27:332063  undefined
        at Object.render (https://jmartin.inrupt.net/mashlib.min.js:27:332090)  undefined
        at _.propertyTable (https://jmartin.inrupt.net/mashlib.min.js:21:35517)  undefined
        at u (https://jmartin.inrupt.net/mashlib.min.js:21:42368)

[jeswr]

Following up on the dead resource link in this issue (agent-assisted triage for @jeswr).

The referenced URLs are permanently gone. jmartin.inrupt.net no longer resolves (DNS ENOTFOUND). Per Inrupt's service-migration notice, inrupt.net was shut down on 2025-03-31 (10:00 UTC) and merged into Inrupt PodSpaces. PodSpaces Pods now live at https://storage.inrupt.com/{pod-id}, where the Pod identifier is autogenerated (PodSpaces also introduced a new WebID format allowing multiple Pods per WebID). Because the new Pod IDs are not derived from the old <username>.inrupt.net subdomain, there is no deterministic or publicly discoverable equivalent URL for the original jmartin.inrupt.net/public/shapes/book-shacl.ttl — it would only exist inside that user's migrated (private) PodSpaces storage.

The second, replication copy at megoth.solid.community/public/testdir/book-shacl.ttl is also gone (that server refuses connections now). I checked the Wayback Machine for both URLs and there is no archived snapshot of either, so the exact book-shacl.ttl content appears unrecoverable from its original locations.

Does this resolve the issue? No — leaving it open. The dead link was only the evidence, not the bug itself. The report is that a SHACL/Turtle file whose source view parses and validates fine crashes the data view with Error: Unhandled node type: undefined, and the stack trace is entirely in the data-browser rendering layer (mashlib → statementsAsTables / propertyTable), not in rdflib's Turtle parser. So this looks like a genuine rendering bug — a term with an undefined termType reaching the table renderer — that is independent of the now-dead URL, but it cannot be reproduced without the failing content.

What's needed to proceed: the failing file content. If anyone still has a copy of that book-shacl.ttl (or can produce a minimal SHACL .ttl that reproduces Unhandled node type: undefined in the data browser), please paste it inline here. With a repro this can be diagnosed and routed to the right layer (most likely mashlib/solid-ui, or rdflib if it turns out to be emitting a malformed term).

[bourgeoa]

solid.community was migrated to solidcommunity.net but may be not all internal URL's.
The link exist at https://megoth.solidcommunity.net/public/testdir/

[jeswr]

Thanks @bourgeoa — that is a useful lead. I tried to retrieve https://megoth.solidcommunity.net/public/testdir/book-shacl.ttl for testing, but solidcommunity.net now fronts requests with a Cloudflare managed challenge (a JavaScript/browser check), so non-browser clients receive the challenge page instead of the file; there are also no Wayback Machine snapshots of any of the three URLs mentioned in this thread. If you (or anyone with a browser) can open that URL and paste the raw Turtle inline here, we can immediately test it against rdflib v2.4.0 and against the N3.js-based Turtle parser in draft PR #831, and then route the Unhandled node type: undefined crash to the right layer — the stack trace points at mashlib's statementsAsTables/propertyTable rendering path, so this may ultimately belong in mashlib/solid-ui rather than rdflib. Leaving this open since the content appears recoverable. (Agent-assisted triage for @jeswr, plan #824.)

[jeswr]

(this is the real Jesse)

The response given when viewed in the solidOS UI is

Error: Unhandled node type: undefined
  undefined
    Error: Unhandled node type: undefined  undefined
        at b (https://megoth.solidcommunity.net/mashlib.min.js:2510:30894)  undefined
        at b (https://megoth.solidcommunity.net/mashlib.min.js:2510:30643)  undefined
        at g (https://megoth.solidcommunity.net/mashlib.min.js:2510:29394)  undefined
        at b (https://megoth.solidcommunity.net/mashlib.min.js:2510:30304)  undefined
        at g (https://megoth.solidcommunity.net/mashlib.min.js:2510:29394)  undefined
        at Object.statementsAsTables (https://megoth.solidcommunity.net/mashlib.min.js:2510:31556)  undefined
        at https://megoth.solidcommunity.net/mashlib.min.js:2510:32356  undefined
        at Object.render (https://megoth.solidcommunity.net/mashlib.min.js:2510:32383)  undefined
        at https://megoth.solidcommunity.net/mashlib.min.js:2510:83356

[jeswr]

(this is the real Jesse)

curl gives

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix book: <http://schema.org/Book#> .
@prefix thing: <http://schema.org/Thing#> .
@prefix person: <http://schema.org/Person#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex: <http://example.com/ns#> .

ex:BookShape
    a sh:NodeShape ;
    sh:targetClass schema:Book ;
    sh:property [
        sh:path thing:name ;
        sh:datatype xsd:string ;
        sh:name "Book title" ;
        sh:minLength 19 ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:group ex:DetailsGroup ;
    ] ;
    sh:property [
        sh:path book:bookEdition ;
        sh:or ( [ sh:datatype xsd:string ] [ sh:datatype xsd:integer ] ) ;
        sh:name "Book Edition" ;
        sh:group ex:DetailsGroup ;
    ] ;
    sh:property [
        sh:path book:numberOfPages ;
        sh:datatype xsd:integer ;
        sh:minInclusive 1 ;
        sh:maxInclusive 99999 ;
        sh:name "Number of Pages" ;
        sh:group ex:DetailsGroup ;
    ] ;
    sh:property [
        sh:path book:abridged ;
        sh:datatype xsd:boolean ;
        sh:in (true false) ;
        sh:name "Abridged" ;
        sh:group ex:DetailsGroup ;
    ] ;
    sh:property [
        sh:path person:givenName ;
        sh:datatype xsd:string ;
        sh:minLength 1 ;
        sh:maxLength 100 ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:name "First Name" ;
        sh:group ex:AuthorGroup ;
    ] ;
    sh:property [
        sh:path person:familyName ;
        sh:datatype xsd:string ;
        sh:minLength 1 ;
        sh:maxLength 100 ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:name "Last Name" ;
        sh:group ex:AuthorGroup ;
    ] ;
    sh:property [
        sh:path person:givenName ;
        sh:datatype xsd:string ;
        sh:minLength 1 ;
        sh:maxLength 100 ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:name "First Name" ;
        sh:group ex:IllustratorGroup ;
    ] ;
    sh:property [
        sh:path person:familyName ;
        sh:datatype xsd:string ;
        sh:minLength 1 ;
        sh:maxLength 100 ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:name "Last Name" ;
        sh:group ex:IllustratorGroup ;
    ] ;
    sh:property [
        sh:path book:genre ;
        sh:datatype xsd:string ;
        sh:in ("Science Fiction" "Fantasy" "Romance" "Western" "Non-fiction" "Thriller" "Horror" "Douglas Adams") ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:name "Genre" ;
        sh:group ex:DetailsGroup ;
    ] .

ex:DetailsGroup
    a sh:PropertyGroup ;
    sh:order 0 ;
    rdfs:label "Book Details" .

ex:IllustratorGroup
    a sh:PropertyGroup ;
    sh:order 2 ;
    rdfs:label "Illustrator Name" .

ex:AuthorGroup
    a sh:PropertyGroup ;
    sh:order 1 ;
    rdfs:label "Author Name" .

[jeswr]

Root cause found — this is an rdflib bug, and the parser rework in #831 fixes it. (Agent-assisted diagnosis for @jeswr, plan #824.)

With the raw file above, parse(…, 'text/turtle') on v2.4.0 succeeds (83 statements), but the two sh:in lists come back broken: the current hand-rolled Turtle parser inserts raw JavaScript true/false primitives into Collection elements instead of Literal terms. Minimal repro on v2.4.0:

$rdf.parse('@prefix ex: <http://ex.org/>. ex:s ex:p (true false "x" 42).', store, base, 'text/turtle')
// Collection elements: RAW-JS boolean true, RAW-JS boolean false, Literal("x"), Literal("42")

Strings and numbers inside lists become proper Literals — it is specifically the boolean bareword path. Any downstream code that switches on termType then crashes on the undefined type:

• mashlib: statementsAsTables → Error: Unhandled node type: undefined — exactly the SolidOS crash above; and
• rdflib itself: re-serializing the same store fails with Internal: atomicTermToN3 cannot handle true of termType: undefined.

So mashlib is only where the symptom surfaces; the defect is in rdflib's Turtle parser.

Verified against the #831 branch (Turtle-family parsing via N3.js): the same input yields Literal("true")/Literal("false") with proper xsd:boolean datatypes, the full book-shacl.ttl store round-trips, and the crash input is gone. I've added Closes #352 to #831 so this closes when it lands.

[bourgeoa]

I came to the same conclusion.
The problem is not to break existing data flow. I did not check but suppose that the Store internally uses 0/1