Linking failure with the uri property on AssociationLink

Linking failure with the uri property on AssociationLink

In the context file, we have "uri": "@id" based on the change made May 19,2021 (B1 Version History) which effectively maps uri to @id. This means that wherever we see the uri property, the machine sees @id, the URI identifying the resource in which the uri appears. So far as I can tell from the examples in the spec, this mapping works with the following significant exception.

In the new AssociationLink class, the uri is defined as: "The uri of the link target". This definitionally aligns the uri property in the AssociationLink to the destinationNodeURI property in (defined as "The resolvable URI for the destination node object"). In other words it is intended to point to the destination node of the AssociationLink instance being described. This means that in the CASE-LD spec, URI has two conflicting meanings:

  1. The @id of the AssociationLink; and
  2. The destination object of the AssociationLink.

The result is that meaning #1 in the context file overrides the intended meaning #2 in all instances of the AssociationLink class. The result of the over-ride is that all instances of AssociationLink link to nothing.

I have attached a .png file here as CFItem.png that visually graphs the CFItem example in the spec. Note the CFItem node on the far left that links to the dtAssociationLink node (center of image). Note that this node has no outbound uri property identifying the destination/target of the association. That is because the uri was converted to @id and names/identifies the dtAssociationLink (check out its URI). Totally not what was intended. Possible solution is not to use uri here but rather a property like the destinationNodeURI property in the original JSON spec, something that is not over-ridden by anything in the context file.