Allowing << a b c>> caused_by <<a d e>> would seems like a trivial thing to implement and it would allow meta-assertions about assertions. I can understand why the edge property syntax is disallowed for properties. Why was it disallowed in the object position of a sentence?
The purpose of this restriction was to minimize the performance impact of enabling edge properties specifically for the cascading deletes. Deleting any statement requires us to check if that statement is used as the subject of another statement so all those statements can be deleted. Allowing statements to appear as objects would require us to do one more lookup for each deleted statement. For this reason, we wanted to be conservative initially and restrict the usage.
In the future we can modify the configuration option to enable edge properties with and without object position support for a pay-as-you-go approach. We have already designed the API to allow statements to appear as objects.
Best,
Evren
Thanks for the explanation. In the scenario I used, only the "caused_by" sentence would be subject to cascading delete. However, the general problem of cascading delete is not solvable without some metadata associated with the edge property sentence. While this metadata could be associated with the edge property predicate URL, it would add code to determine what to do when the subject or object sentence is deleted. Perhaps this could be enabled, as edge properties are, for those cases where the user is willing to tolerate the additional overhead. In the absence of metadata, the default would be to just delete the edge property sentence if either the subject sentence or the object sentence is deleted. If the edge property predicate was marked "cascade", the recursive cascade would be executed. I would be OK if sentences are disallowed in the predicate position.
Jim