1

disclosure: this one is a bit stale on msdn Hi there, the spacePaths=string[] attribute suggest that space objects can have multiple parents. That there can be multiple routes to an object. But then there's only one parent object to a space... which one is it? Is "moving" an object in the graph achieved by simply running a Patch on a space object with a different parent id? Is there documentation about the available "includes" for the different api's? for instance the spacePaths attribute for space objects is included if you add "fullpath" to the query... is there a way to obtain the full object model - the default on includes is typically none. Kind regards, Gregor

Gregor
  • 134
  • 8

4 Answers4

2

Currently it's a tree through Parent Space ID. We're discussing internally how best to support many-to-many relationship while keeping the simplicity of our topologies. In the meantime, we do see the tree enabling many core scenarios for developers and in some cases we've seen people build around the single-parent relationship by using extensible properties to tag additional related spaces. There's a limitation in extended types/ontologies in terms of creating a spaceObject type in general extending the topology; we're looking to improve ontologies and are keeping this mind with our planning/requests. As a side note, if you want to ask for new features/concepts I recommend posting to feedback.azure.com: https://feedback.azure.com/forums/916621-azure-digital-twins as we are actively using this to inform our scenarios :)

1

the spaces are represented as a tree, thus each space can only have 0 or 1 parent. You can move a space by changing its parentSpaceId attribute, but when it has a value, apparently you cannot remove it... Bug or by design?

In my current test Digital Twin, the spacePaths attribute always contains only 1 item, as I would expect. That doesn't make sense to me to have several parents in a tree. I didn't find any documentation on that either, maybe when it will be GA? The fact that it is an array is puzzling indeed.

Sorry for not being able to help much.

Cheers, fred

Fred Mauroy
  • 1,219
  • 1
  • 11
  • 10
  • Good observations. Thanks for your insight. I think MS has to clean this up a bit: they can't go around and call it a graph - if it is indeed a tree. One) there are use cases where you'd want multiple parents, especially if space objects are used to model different business uses and two) it certainly would make things like permission inheritance more complicated. Maybe one could have a primary parent for "keeping the tree", and allow secondary edges to enable graph-like relationships. Did you test changing parent Id's? What if there are different user assignment at the new parent? – Gregor Nov 02 '18 at 14:38
  • I see what you mean. Maybe someone from Microsoft will chime in on this? As per your question about changing a parentId, it worked in my tests. The node is simply moved to another part of the tree. I can expect that the users assigned above will percolate to that "new" node. We plan to use user assignments only on tenants, and not below, at least during our PoC with this preview tool. – Fred Mauroy Nov 03 '18 at 16:17
0

One of possible option to define "parents" like "children" to handle multiple parents to space instead parentSpaceId. Or use edge to have relation. There should be a method to added to Parents for a spaceID.

Definitely it is needed requirement to have graph model of space.

0

1st question (is it a tree or a graph): it's a tree and there are ways to get around single-parent restrictions by applying custom attributes.

2nd question (how to move space elements): space elements can be moved by patching with new parentSpaceId attributes. when changing the parentSpaceId permissions will adjust accordingly.

3rd question (what are the "includes" choices): the includes are a bit tricky, but a good way to study them is to use the swagger document and "try" the different routes (for instace get: /api/v1.0/spaces). those "includes" are dropdowns and they populate with the available choices.

avoiding responding to other answers: thank you Fred and Bobbie for your insight.

Gregor
  • 134
  • 8