Dropping @dependencies in favour of using @properties?

[draggett]

@dependencies is essentially syntactic sugar for defining properties whose values are things. We could just drop @dependencies and use @properties along with an associative array with metadata field names including "type" and "uri", e.g.

{
  @properties {
      door: { type: "thing", "uri": "door12" },
      light: { type: "thing", "uri": "switch12" }
   }
}

where "uri" gives the URI for the thing's description. This syntax is a little more verbose, but would win when it comes to providing additional metadata for the things this thing depends upon. What do you all think about this change?

[mpetyx]

I am in favour of this, since @dependencies is just an abbreviation more or less of what's there and is essential for the Thing. In my opinion I would expecting something more like:

{
  "@properties":{

    "door":{
      "type": "thing",
      "uri": "door.json",
      "_links":{
        "self": {"href":"door12"}
      }
    },

    "light":{
      "type": "thing",
      "uri": "switch.json",
      "_links":{
        "self": {"href":"light12"}
      }
    }
  }
}

Personally I would even prefer going a little bit deeper on json-ld and having the representations of each embedded object into a dereferencable resource depicting an actual object. This way I could uniquely create the door12 that is an actual URI. In general, I agree with deprecating @dependencies.

[draggett]

I am doubtful about binding the thing's model and instance as part of another thing's description. That would seem to risk maintenance problems in a distributed system. Instead, I would allow for the thing descriptions to define their models by reference to an external definition that can be shared across many things of the same kind. The open world hypothesis of linked data would allow you to provide metadata specific to a given device in combination with the shared model.

[bubbafat]

I'm personally on the side of leaving them separate. I'm thinking of scenarios like:

• Binding properties to a UI
• Logical equality of things (which may or may not include dependents)
• Performance issues

Binding and equality (of properties with values) would require that everyone always filter out dependencies. From a performance side it will require enumerating over all properties to find if there are any dependencies - this might not be a big deal but when you are talking about two or three items, but how about a sensor network with 8 million nodes each of which have hundreds of properties (e.g., a smart meter network deployed in a large urban area). Now you are performing billions of string comparisons that don't need to be performed.

I think the sugar, in this case, adds more value than just syntax.