Re: [protege-user] JSON-LD ontology won't load in Protege

Jamie McCusker <[email protected]> Mon, 29 Dec 2025 20:02:06 -0500
Newsgroups gmane.comp.misc.ontology.protege.owl
Message-ID <CAAtgn=SOPXd8zu+oBRdHQ7JZADck79Sh4ckZv6M3bX7YA9qGsQ@mail.gmail.com>
--===============0908910262076219264==
Content-Type: multipart/alternative; boundary="0000000000004a9a06064720e9dc"

--0000000000004a9a06064720e9dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Try loading into the JSON-LD playground at jsonld.org to validate before
using something like Chat GPT. =F0=9F=98=81

Jamie McCusker (she/her/hers)

The Opinionated Ontologist


On Mon, Dec 29, 2025 at 11:10=E2=80=AFAM Michael DeBellis <mdebellissf@gmai=
l.com>
wrote:

> I haven't use JSON LD much so I pasted the file into ChatGPT. Here's the
> feedback I got:
>
> As **pasted**, I would not call it =E2=80=9Cvalid JSON-LD=E2=80=9D, for t=
wo separate
> reasons:
>
> ## 1) It isn=E2=80=99t valid JSON as pasted
>
> * Everything after the final `}` (the =E2=80=9C=E2=98=9B Click the line n=
umbers=E2=80=A6 powered
> by =E2=80=A6=E2=80=9D text) makes the whole paste **not JSON**.
> * There=E2=80=99s also a suspicious standalone =E2=80=9Cblank=E2=80=9D li=
ne right before the
> `fgb:Data` node that looks like a **non-breaking space** (U+00A0). JSON
> only allows whitespace characters `space`, `tab`, `CR`, `LF`. A literal
> NBSP character can make a JSON parser fail even though it *looks* like
> normal whitespace.
>
> If you delete the non-JSON footer text and ensure that =E2=80=9Cblank=E2=
=80=9D line is a
> normal newline (or remove it), it will likely parse as JSON.
>
> ## 2) Even if it parses, it likely won=E2=80=99t generate the RDF you int=
end
> (JSON-LD modeling issue)
>
> In JSON-LD, a string like `"fgb:File"` is treated as an **IRI** only when
> the *property* is defined in the context as an IRI-valued property (i.e.,
> `@type: "@id"`), or you use an object form like `{ "@id": "fgb:File" }`.
>
> Right now you have lots of places like:
>
> * `"rdfs:subClassOf": "dcat:Dataset"`
> * `"rdfs:domain": "fgb:File"`
> * `"rdfs:range": "fgb:Header"`
> * `"owl:onProperty": "fgb:hasHeader"`
> * `"owl:allValuesFrom": "xsd:boolean"`
> * `"rdfs:isDefinedBy": "fgb:"`
>
> Unless you add coercions in `@context`, many of those will become **strin=
g
> literals** (e.g., `"dcat:Dataset"` as a literal) instead of IRIs =E2=80=
=94 which
> will break OWL semantics in tools.
>
> ### Minimal fix pattern
>
> Add IRI coercions in the context for the properties that should point to
> resources/classes/properties:
>
> ```json
> "rdfs:subClassOf": { "@type": "@id" },
> "rdfs:subPropertyOf": { "@type": "@id" },
> "rdfs:domain": { "@type": "@id" },
> "rdfs:range": { "@type": "@id" },
> "rdfs:isDefinedBy": { "@type": "@id" },
>
> "owl:onProperty": { "@type": "@id" },
> "owl:allValuesFrom": { "@type": "@id" },
> "owl:someValuesFrom": { "@type": "@id" },
> "owl:hasValue": { "@type": "@id" }
> ```
>
> Alternatively, change values to object form everywhere (more verbose),
> e.g. `"rdfs:subClassOf": { "@id": "dcat:Dataset" }`.
>
> ---
>
> ### Bottom line
>
> * **Not valid JSON(-LD) as pasted** (extra footer text; likely NBSP line)=
.
> * **Once cleaned**, it can be valid JSON-LD syntax, but **you should add
> `@type: "@id"` coercions** (or use `{ "@id": ... }`) or you=E2=80=99ll ge=
t lots of
> literals where you intended IRIs.
>
>
>
> On Sat, Dec 27, 2025 at 6:39=E2=80=AFPM Reese Ricci Armstrong via protege=
-user <
> [email protected]> wrote:
>
>> I=E2=80=99m racking my brain trying to get this ontology to load into Pr=
otege,
>> and I=E2=80=99m hoping someone might be able to provide some insight.
>>
>> https://commie.io/#9wfhhBll
>>
>> In solidarity,
>>
>> --reese
>> _______________________________________________
>> protege-user mailing list
>> [email protected]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>
> _______________________________________________
> protege-user mailing list
> [email protected]
> https://mailman.stanford.edu/mailman/listinfo/protege-user
>

--0000000000004a9a06064720e9dc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Try loading into the JSON-LD playground at <a href=3D"htt=
p://jsonld.org">jsonld.org</a> to validate before using something like Chat=
 GPT. =F0=9F=98=81<br clear=3D"all"><br clear=3D"all"><div><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr"><div style=3D"font-family:arial;font-size:small">=
Jamie McCusker (she/her/hers)<br></div><div style=3D"font-family:arial;font=
-size:small"><br></div><div style=3D"font-family:arial;font-size:small">The=
 Opinionated Ontologist</div></div></div></div></div></div></div><div><br><=
/div><div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"=
ltr" class=3D"gmail_attr">On Mon, Dec 29, 2025 at 11:10=E2=80=AFAM Michael =
DeBellis &lt;<a href=3D"mailto:[email protected]">[email protected]=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-lef=
t:1ex;border-left-color:rgb(204,204,204)"><div dir=3D"ltr">I haven&#39;t us=
e JSON LD much so I pasted the file into ChatGPT. Here&#39;s the feedback I=
 got:<br><br>As **pasted**, I would not call it =E2=80=9Cvalid JSON-LD=E2=
=80=9D, for two separate reasons:<br><br>## 1) It isn=E2=80=99t valid JSON =
as pasted<br><br>* Everything after the final `}` (the =E2=80=9C=E2=98=9B C=
lick the line numbers=E2=80=A6 powered by =E2=80=A6=E2=80=9D text) makes th=
e whole paste **not JSON**.<br>* There=E2=80=99s also a suspicious standalo=
ne =E2=80=9Cblank=E2=80=9D line right before the `fgb:Data` node that looks=
 like a **non-breaking space** (U+00A0). JSON only allows whitespace charac=
ters `space`, `tab`, `CR`, `LF`. A literal NBSP character can make a JSON p=
arser fail even though it *looks* like normal whitespace.<br><br>If you del=
ete the non-JSON footer text and ensure that =E2=80=9Cblank=E2=80=9D line i=
s a normal newline (or remove it), it will likely parse as JSON.<br><br>## =
2) Even if it parses, it likely won=E2=80=99t generate the RDF you intend (=
JSON-LD modeling issue)<br><br>In JSON-LD, a string like `&quot;fgb:File&qu=
ot;` is treated as an **IRI** only when the *property* is defined in the co=
ntext as an IRI-valued property (i.e., `@type: &quot;@id&quot;`), or you us=
e an object form like `{ &quot;@id&quot;: &quot;fgb:File&quot; }`.<br><br>R=
ight now you have lots of places like:<br><br>* `&quot;rdfs:subClassOf&quot=
;: &quot;dcat:Dataset&quot;`<br>* `&quot;rdfs:domain&quot;: &quot;fgb:File&=
quot;`<br>* `&quot;rdfs:range&quot;: &quot;fgb:Header&quot;`<br>* `&quot;ow=
l:onProperty&quot;: &quot;fgb:hasHeader&quot;`<br>* `&quot;owl:allValuesFro=
m&quot;: &quot;xsd:boolean&quot;`<br>* `&quot;rdfs:isDefinedBy&quot;: &quot=
;fgb:&quot;`<br><br>Unless you add coercions in `@context`, many of those w=
ill become **string literals** (e.g., `&quot;dcat:Dataset&quot;` as a liter=
al) instead of IRIs =E2=80=94 which will break OWL semantics in tools.<br><=
br>### Minimal fix pattern<br><br>Add IRI coercions in the context for the =
properties that should point to resources/classes/properties:<br><br>```jso=
n<br>&quot;rdfs:subClassOf&quot;: { &quot;@type&quot;: &quot;@id&quot; },<b=
r>&quot;rdfs:subPropertyOf&quot;: { &quot;@type&quot;: &quot;@id&quot; },<b=
r>&quot;rdfs:domain&quot;: { &quot;@type&quot;: &quot;@id&quot; },<br>&quot=
;rdfs:range&quot;: { &quot;@type&quot;: &quot;@id&quot; },<br>&quot;rdfs:is=
DefinedBy&quot;: { &quot;@type&quot;: &quot;@id&quot; },<br><br>&quot;owl:o=
nProperty&quot;: { &quot;@type&quot;: &quot;@id&quot; },<br>&quot;owl:allVa=
luesFrom&quot;: { &quot;@type&quot;: &quot;@id&quot; },<br>&quot;owl:someVa=
luesFrom&quot;: { &quot;@type&quot;: &quot;@id&quot; },<br>&quot;owl:hasVal=
ue&quot;: { &quot;@type&quot;: &quot;@id&quot; }<br>```<br><br>Alternativel=
y, change values to object form everywhere (more verbose), e.g. `&quot;rdfs=
:subClassOf&quot;: { &quot;@id&quot;: &quot;dcat:Dataset&quot; }`.<br><br>-=
--<br><br>### Bottom line<br><br>* **Not valid JSON(-LD) as pasted** (extra=
 footer text; likely NBSP line).<br>* **Once cleaned**, it can be valid JSO=
N-LD syntax, but **you should add `@type: &quot;@id&quot;` coercions** (or =
use `{ &quot;@id&quot;: ... }`) or you=E2=80=99ll get lots of literals wher=
e you intended IRIs.<br><br><br></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Sat, Dec 27, 2025 at 6:39=E2=80=AFPM Ree=
se Ricci Armstrong via protege-user &lt;<a href=3D"mailto:protege-user@list=
s.stanford.edu" target=3D"_blank">[email protected]</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;bord=
er-left-color:rgb(204,204,204)">I=E2=80=99m racking my brain trying to get =
this ontology to load into Protege, and I=E2=80=99m hoping someone might be=
 able to provide some insight.<br>
<br>
<a href=3D"https://commie.io/#9wfhhBll" rel=3D"noreferrer" target=3D"_blank=
">https://commie.io/#9wfhhBll</a><br>
<br>
In solidarity,<br>
<br>
--reese<br>
_______________________________________________<br>
protege-user mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">proteg=
[email protected]</a><br>
<a href=3D"https://mailman.stanford.edu/mailman/listinfo/protege-user" rel=
=3D"noreferrer" target=3D"_blank">https://mailman.stanford.edu/mailman/list=
info/protege-user</a><br>
</blockquote></div>
_______________________________________________<br>
protege-user mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">proteg=
[email protected]</a><br>
<a href=3D"https://mailman.stanford.edu/mailman/listinfo/protege-user" rel=
=3D"noreferrer" target=3D"_blank">https://mailman.stanford.edu/mailman/list=
info/protege-user</a><br>
</blockquote></div></div>

--0000000000004a9a06064720e9dc--

--===============0908910262076219264==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
protege-user mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/protege-user

--===============0908910262076219264==--