You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not entirely satisfied with the addition in common/terms.html,
as it seems too detailed for the terminology section. But...
...as pointed out in the comment of #630,
the API spec references to this definition in multiple places,
and many of those links are actually for instances of the internal representation,
*not* for instances of the strings or maps that represent term definition in JSON.
So the alternative would be to introduce a new name for those "internal term definition"
and patch all the algorithms... which seems laborious and error-prone.
@gkellogg I don't remember what's the process for synchronizing the files in common with other specs.
Copy file name to clipboardexpand all lines: common/terms.html
+2-1
Original file line number
Diff line number
Diff line change
@@ -382,7 +382,8 @@
382
382
as a key, type, or elsewhere that a string is interpreted as a vocabulary item.
383
383
Its value is either a string (<dfndata-cite="JSON-LD11#dfn-simple-term-definition" data-lt="simple term definition|simple term" data-lt-noDefault>simple term definition</dfn>),
384
384
expanding to an <a>IRI</a>,
385
-
or a map (<a>expanded term definition</a>).
385
+
or a map (<a>expanded term definition</a>).<br/>
386
+
<spanclass="change">For <adata-cite="JSON-LD11-API#context-processing-algorithms">context processing</a>, <a>term definitions</a>' values are converted internally to a dedicated data structure</span> that is easier to process.
0 commit comments