Community Request for Comments: non-targeted Relationships (DTDL) / Object Properties (SHACL)

[hammar]

(In the below, DTDL terminology is used; if you're a SHACL user, substitute the word Relationship with Object Property)

Dear all,

Resulting from @cbupp's question #149 in this discussion forum, the RealEstateCore Technical Committee at our meeting yesterday spent some time discussing whether to implement an non-targeted Agent.owns Relationship, that is, one unbound by a Target (SHACL: rdf:range) declaration, and that could consequently be used to indicate agents' ownership of any thing in the graph. The discussion soon scaled up to a principles discussion on the merits, or lack thereof, of such non-targeted Relationship declarations.

After some back-and-forth, we realized the tradeoffs warrant a broader community discussion, and I was tasked to initiate it.

In the below, I'm exemplifying with Agent.owns and it's inverse(s) Architecture.ownedBy, Collection.ownedBy, etc., but the idea is to try and think beyond these cases and about the generic design pattern in question.

Arguments in favor of using non-targeted Relationships:

1. Decreased maintainability -- one can establish such Relationships once and they are very broadly applicable across any target type in the graph. If we instead elect to go the other way and establish .ownedBy Relationships on everything which is ownable, then we create a great many relationships, all of which we might need to maintain over time.
2. Flexibility -- we cannot a priori know every use case people might use REC for; giving this flexibility allows for people to construct graphs of shapes we did not originally plan for.

Arguments for using only Relationships with defined Targets:

1. Increased usability/explorability -- users of the ontology will (through appropriate tool support, like our documentation generation tooling) always be able to check which Relationships that go into or out of a given datatype (DTDL Interface or SHACL NodeShape). I.e., it will always be explicit which Relationships that are relevant for a given datatype; nothing is hidden away in a Relationship declaration in some obscure type elsewhere.
2. It is more opinionated and prescriptive, and prevents modelling unreasonable constructs. This is a counterpoint to (2) above; we constrain developer flexibility, but in so doing we also provide greater assurances of data/system compatibility, since the graphs will display a more regular/well-defined representation, and developers need to code for fewer edge cases.

There are surely more arguments in either direction. Please make your voice heard here about what you prefer (either through voting or through comments), and we'll take that into the development cycle as we continue to push for REC4 GA.

[hammar]

Example illustration

[cbupp]

Thanks @hammar and others on the TC for the thoughtful consideration.

For my immediate use case, we can align to either decision.

Restricting to Targeted relationships would also impact Portfolio's includes and Equipment's feds.

[PeteHart]

I tend towards the targeted relationships... having been building platforms that, eventually, should be consumable by applications not build by ourselves, I feel that such application development would be easier with a stricter "schema" in the ontology. And for me easier implies faster adoption of REC by applications.

I see the application adoption as a core part in realizing the vision of an open standard. That is that application and platform development may be separated, and property owners that would expose an REC API can select among a larger set of compliant applications.

I suppose my argument is that more work in the ontology as well as making it more opinionated which shorter term may be cumbersome for developers that work on both platform and applications is balanced by the longer term upsides

[hammar]

I'm spreading the link to this discussion a little further among colleagues and interested parties, hoping to get a little larger feedback set.

For my part, I am really torn on the matter and could go either way.

[gtfierro]

Hi all:

I am also torn between the two designs, but am leaning towards targeted relationships. Given the use of SHACL over OWL, it is possible to model a relationship as having a set of possible object types. For example, in Brick, we use SHACL to enforce that the feeds relationships should point from Equipment to (Equipment or Location).

I think the key feature for flexibility in modeling is to ensure that the object types of the relationship are broad enough that most extensions can fit beneath those types. In Brick, some of the most common extensions are adding new kinds of equipment and points. As we advise in our documentation, extensions should -- when possible -- be placed under one of those broad classes to aid in discoverability.

For this particular discussion, I'm leaning towards targeted relationships with some broad sets of types as the range

[hammar]

Thank you all for your contributions to this discussion.

At the REC Technical Committee meeting today, we decided as follows:

1. We will allow open-ended Relationships but discourage their use unless very clear business need exists; they are to be used sparingly.
2. The Markdown documentation generator will be updated to display such open-ended relationships as incoming (under a special heading) on every Interface description page.
3. Agent.owns belongs to the aforementioned category of rare cases where an open-ended Relationship is appropriate, and it will be added before REC4 GA (thus allowing for organizations to own collections, as requested in the source discussion linked above).

[cbupp]

Is Point.isPointOf another example of an open-ended relationship? Or is there a plan to limit this to Space and Asset targets?

[hammar]

I'd love to limit it in such a way, but given that DTDL only allows for singletons in Relationship.target, see no way of doing so (except implementing some abstract base class specifically for this, e.g., "ICanHavePoints", which Space and Asset would derive from -- and that just seems like too much of a kludge?).