Are "rich" references possible via reference nodes or embedded node objects?

[absoludity]

The project I'm working on (UNTP) has a need to reference external nodes while also including some summary or preview data with the reference so that the referenced node can be represented meaningfully even when it cannot be dereferenced at the time (or may not be dereferencable).

From the spec I think I've understood that a reference node can contain only the @id property.

Click here to expand the example details of where the spec says reference nodes can contain only an `@id` property

From the JSON-LD 1.1 spec intro:

JSON-LD introduces a mechanism in which a value in a JSON object may refer to a resource on a different site on the Web,

In the JSON-LD specific term definitions, we see that a node reference is defined as:

A node object used to reference a node having only the @id key.

That is, a node reference has only a single key: the @id of the node being referenced, such as:

  "@context": {
    "knows": {
      "@id": "http://schema.org/Person"
    }
  },
  ...
  "knows": {
    "@id": "https://example.com/people/Manu"
  },
  ...

which, through the extra type coercion of "@type": "@id" for knows is equivalent to:

  "@context": {
    "knows": {
      "@id": "http://schema.org/Person",
      "@type": "@id",
    }
  },
  ...
  "knows": "https://example.com/people/Manu",
  ...

The Syntax Tokens and Keywords similarly identifies the @id as:

Used to uniquely identify node objects that are being described in the document with IRIs or blank node identifiers. This keyword is described in § 3.3 Node Identifiers. A node reference is a node object containing only the @id property, which may represent a reference to a node object found elsewhere in the document.

I understand this to mean that:

• If a node object contains other properties as well as an @id property, then the @id property is defining the unique identifier for that node object, whereas,
• If the node object contains only the @id property, then the node object is a node reference and the @id property value is a link to a node object elsewhere.

This dual function of the @id property, depending on the other properties present, seems to mean that you can't define a node reference that has extra data as a single node. Or can you?

Yet, the section on embedding with its example 94 populates the "knows" property with a node object consisting of the @id of an external Person node for Greg from Greg's website while also including just Greg's name:

{
  "@context": {
    "@vocab": "http://xmlns.com/foaf/0.1/"
  },
  "@type": "Person",
  "name": "Manu Sporny",
  "knows": {
    "@id": "https://greggkellogg.net/foaf#me",
    "@type": "Person",
    "name": "Gregg Kellogg"
  }
}

This appears to be exactly what I thought the spec was saying shouldn't happen (a reference node with more than an @id property), but perhaps it's just the example and it's meant to be defining a person with the embedded data rather than linking with a bit of extra data (if so, maybe an example other than Person with what appears to be an external IRI would be better). Or maybe this is fine according to the spec and I misunderstood above.

Indeed the small overview section on Node Identifiers seems to imply that the @id of the node can be used to find out more information about the node, as though the "name" and other detail defined in the node here is just part of the information:

{
  "@context": {
    ...
    "name": "http://schema.org/name"
  },
  "@id": "http://me.markus-lanthaler.com/",
  "name": "Markus Lanthaler",
  ...
}

I'm keen to understand whether that is totally fine (and why then the "reference node" sections talks about only having the @id property). Thanks for any info.

[absoludity]

Not suggesting this is valid, but from a programming perspective I'd imagine something like the following that allows the reference link to still have just the one @id property - iff underscore properties are considered hidden / private / non-authoritative :

  {
    "@id": "some-unique-id-1",
    "_cached_properties": {
      "name": "Markus Lanthaler",
      ...
    }
  },
 

Importantly, this also emphasises that they are cached properties (ie. could have been updated since), rather than defining a new entity that includes the properties with the id as if they are a separate node).

[absoludity]

Now I am answering my own question: Rich references appear to be handled fine - rather than defining new nodes, the data is merged together based on the unique @id (ie. the RDF triplets have the same subject). More accurately, it's not a reference, but a separate node object for the same node (@id), which may define the same (or new) properties which will be merged into the resulting node (see below for spec reference).

Using the playground with the following json-ld:

{
  "@context": {
    "@vocab": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "http://manu.sporny.org/about#manu",
  "@type": "Person",
  "name": "Manu Sporny",
  "knows": [{
    "@id": "https://greggkellogg.net/foaf#me",
    "@type": "Person",
    "name": "Gregg Kellogg"
  }, {
    "@id": "http://manu.sporny.org/about#manu",
    "name": "Manu Spornie",
    "@type": "Person"
  }]
}

which happens to have the node with @id "http://manu.sporny.org/about#manu" twice (since he knows himself), but the second definition of the node has a typo in the name. When I look at the flattened representation, it has ensured there is just one node for Manu (due to the unique identifier) and just has both versions of the name in the graph (only two nodes in total, as expected):

{
  "@context": "http://schema.org/",
  "@graph": [
    {
      "id": "http://manu.sporny.org/about#manu",
      "type": "foaf:Person",
      "foaf:knows": [
        {
          "id": "https://greggkellogg.net/foaf#me"
        },
        {
          "id": "http://manu.sporny.org/about#manu"
        }
      ],
      "foaf:name": [
        "Manu Spornie",
        "Manu Sporny"
      ]
    },
    {
      "id": "https://greggkellogg.net/foaf#me",
      "type": "foaf:Person",
      "foaf:name": "Gregg Kellogg"
    }
  ]
}

If I correct the typo on the name, then it just collapses to:

{
  "@context": "http://schema.org/",
  "@graph": [
    {
      "id": "http://manu.sporny.org/about#manu",
      "type": "foaf:Person",
      "foaf:knows": [
        {
          "id": "https://greggkellogg.net/foaf#me"
        },
        {
          "id": "http://manu.sporny.org/about#manu"
        }
      ],
      "foaf:name": "Manu Sporny"
    },
    {
      "id": "https://greggkellogg.net/foaf#me",
      "type": "foaf:Person",
      "foaf:name": "Gregg Kellogg"
    }
  ]
}

This is perhaps more obvious if looking at the RDF triplets for the document. When including the typo, the RDF triplets (in table format) look like:

But if I fix the typo, then the duplicated RDF triplet is removed (so there is only one entry for Manu's name).

So there does not appear to be any issue defining reference nodes with more than the @id property, at least in the way it is handled. Perhaps the spec is just trying to say that you can only refer to a node as a "node reference" if it only contains the @id property, otherwise it is a node object (that may get merged with other node objects of the same @id)?

In fact, now that I know what to look for, i can see this explicitly defined in the spec under node objects:

The properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node.

[BigBlueHat]

So there does not appear to be any issue defining reference nodes with more than the @id property, at least in the way it is handled. Perhaps the spec is just trying to say that you can only refer to a node as a "node reference" if it only contains the @id property, otherwise it is a node object (that may get merged with other node objects of the same @id)?

Exactly that. 😃 Essentially, it's "only" a reference when it's only the @id value. If you make statements about it by adding properties, you've created a node object.

There's no requirement nor guarantee that a reference will ever be (nor can be) dereferenced, so if there is a need to include "local knowledge" about an identifier (which may or may not be a locator), that is done via a "node object".

And, as you've discovered, when multiple sets of statements are put into a single graph, they're additive (unless equivalent). Other technologies can/are used (before or after consumption) to determine what statements should be kept (or exported) from a single graph.

Great work sorting that out @absoludity!
🎩

[absoludity]

Thanks for the confirmation :)