Azure / opendigitaltwins-dtdl

Digital Twins Definition Language
Creative Commons Attribution 4.0 International
462 stars 160 forks source link

relationships should support multiple targets and/or multiple versions #133

Open uriel-kluk opened 1 year ago

uriel-kluk commented 1 year ago

Example

{
 "@id": "dtmi:MeshSystems:core:space;1",
 "@context": [
  "dtmi:dtdl:context;2"
 ],
 "@type": "Interface",
 "displayName": "Space",
 "contents": [
  {
   "@type": "Relationship",
   "name": "hosts",
   "target": "dtmi:MeshSystems:core:device;2"
  }
 ]
}

As an ontology designer, I would like space to host different devices "target": "dtmi:MeshSystems:core:device;*"

Instead of the wildcard * the version could be omitted, this is just an idea.

or "target": ["dtmi:MeshSystems:core:device;1", "dtmi:MeshSystems:core:device;2"]

rido-min commented 1 year ago

Hi @uriel-kluk

Can you use two relationships? one for each version

/c @cschormann

uriel-kluk commented 1 year ago

Thanks, Rido,

The challenge is when you migrate models and break the relationships.

Assume you have a Gateway that targets leaf devices. (in some cases, 1000s as in LoRa gateways). Then, during the lifecycle of the leaf devices, the model changes. But we cannot migrate unless we update models on all the devices (this could require OTA) and the gateway at once.

The options we are evaluating as workarounds:

  1. Multiple relationships as you mentioned, but now we need different queries
  2. Create a base atomic model with the relationship to extend the leaf devices.
  3. Do not include the target in the relationship.

Something we would like to suggest is for ADT to support a Target with multiple versions:

{ @.": "dtmi:MeshSystems:core:gateway;1", @.": "Interface", @.": "dtmi:dtdl:context;2", "extends": "dtmi:MeshSystems:core:device;1", "displayName": "Gateway", "contents": [ { @.": "Relationship", "name": "contains", "target": "dtmi:MeshSystems:core:device;*", "properties": [ { @.": "Property", "name": "rssi", "schema": "integer" }, { @.": "Property", "name": "eventType", "schema": "string" } ] } ] }

From: Rido @.> Sent: Friday, January 27, 2023 9:30 AM To: Azure/opendigitaltwins-dtdl @.> Cc: Uriel Kluk @.>; Mention @.> Subject: Re: [Azure/opendigitaltwins-dtdl] relationships should support multiple targets and/or multiple versions (Issue #133)

Hi @uriel-klukhttps://github.com/uriel-kluk

Can you use two relationships? one for each version

/c @cschormannhttps://github.com/cschormann

— Reply to this email directly, view it on GitHubhttps://github.com/Azure/opendigitaltwins-dtdl/issues/133#issuecomment-1406660412, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJ2NCAYMNJQAKKQ32QIMHR3WUPSY5ANCNFSM6AAAAAAQTFZ7YY. You are receiving this because you were mentioned.Message ID: @.**@.>>

nikoraes commented 7 months ago

+1 on this I would certainly propose to have something like this: "target": ["dtmi:MeshSystems:core:device;1", "dtmi:MeshSystems:core:device;2"] instead of wildcards.

We have multiple OWL ontologies where the same relationship name is used with multiple targets to enforce specific hierarchies. We convert them to DTDL, but we currently have to ignore these targets because of this limitation.

Here's an example of how we represent this in OWL (TTL)

###  https://data.arcadis.com/otl/bridge#ArchBridge
:ArchBridge rdf:type owl:Class ;
            rdfs:subClassOf :Bridge ,
                            [ rdf:type owl:Restriction ;
                              owl:onProperty core:hasPart ;
                              owl:someValuesFrom :Arch
                            ] ,
                            [ rdf:type owl:Restriction ;
                              owl:onProperty core:hasPart ;
                              owl:someValuesFrom :Crown
                            ] ,
                            [ rdf:type owl:Restriction ;
                              owl:onProperty core:hasPart ;
                              owl:someValuesFrom :Extrados
                            ] ;
            skos:definition "A bridge whose main support structure is an arch. Additionally, the bridge may be termed a through arch, which is simply one where the roadway appears to go through the arch."@en ;
            skos:prefLabel "Arch Bridge"@en ;

the hasPart relationship should ideally be defined like this, which isn't possible

...
 "contents": [
 ...
  {
   "@type": "Relationship",
   "name": "hasPart",
   "target": ["dtmi:com:arcadis:bridge:Arch;1","dtmi:com:arcadis:bridge:Crown;1","dtmi:com:arcadis:bridge:Extrados;1"]
  }
 ]

We've considered the proposed workaround as well (multiple relationship names, creating an abstract class like ArchBridgePart), but as these ontologies are also used by other applications (RDF based), we don't want to adapt the ontologies to the limitations of DTDL. In addition, we're generating about 10000 DTDL models and it would blow up the size significantly (and it would add even more complexity to our internal OWL2DTDL implementation).

Our current workaround would be to store the targets in the comment and read those in the client (so not enforcing them in ADT). But this isn't really a sustainable workaround.

jrdouceur commented 7 months ago

Something we would like to suggest is for ADT to support a Target with multiple versions:

As it happens, ADT ignores the version suffix of Relationship targets. So, if your model specifies:

"target": "dtmi:MeshSystems:core:device;2"

Then the target of any Relationship instances can have type dtmi:MeshSystems:core:device;1, dtmi:MeshSystems:core:device;2, dtmi:MeshSystems:core:device;3, or dtmi:MeshSystems:core:device;10000.

If you are using DTDL v3, you can omit the version suffix from the target property value, which will make the matching semantics a bit clearer:

"target": "dtmi:MeshSystems:core:device"