Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Directories store TD Models as well as Instances? #58

Open
mmccool opened this issue Aug 24, 2020 · 6 comments
Open

Should Directories store TD Models as well as Instances? #58

mmccool opened this issue Aug 24, 2020 · 6 comments

Comments

@mmccool
Copy link
Contributor

mmccool commented Aug 24, 2020

  • For developer time use case (see Add horizontal Discovery use case wot-usecases#33)
  • Would also like a "link" from Instances to Models
  • Models need to live somewhere with stable URLs
  • Convenient if they are in the same directory service as TD instances, with the same API, query support, etc.
  • Could still store instances and models in different databases in practice
  • Complications: directories needs to know if a particular TD-like-file is a TD or a TDM so it can apply the correct validation procedure
@mmccool
Copy link
Contributor Author

mmccool commented Aug 24, 2020

To capture:

  • npm comparison
  • Digital twin use cases
  • Vorto use case (stores models)
  • ODM connection/components (convert to TDMs?)
  • Normative "Link" relation types in TDs to TDMs ("implements") and maybe ODM capabilities (or TDMs representing those capabilities)
  • probably want the ability to discover TD instances that "implement" certain TDMs

To elaborate:

  • Use case workflows, esp for development
  • How does this relate to profiles?

@relu91
Copy link
Member

relu91 commented Oct 27, 2020

npm comparison

If we use npm as a similar concept, Thing Models are not needed at run time. Developers will download TMs and use the downloaded document at run time (i.e. create TDs, Discovery other TDs, etc.). Just like npm has npm install. I really don't see a strict requirement to have TM in a TDD, probably it would be better to define a different service (i.e. a Thing Model Directory).

@memelet
Copy link

memelet commented Feb 26, 2021

@mmccool Would you elaborate the context for “digital twin”? In general I’m struggling to see how wot distinguishes between the actual thing and it’s twin.

... After searching and reading thru the wot projects, it seems that a TD with bindings would be defined for the physical device (akin to an edgex device service or hono’s concept of a device), and a separate TD with probably different bindings would be defined for the twin (akin to ditto’s concept of a thing).

In short, wot seems to not model concept of device vs device-twin in any concrete way. Is this understanding correct?

@relu91
Copy link
Member

relu91 commented Mar 1, 2021

@mmccool Would you elaborate the context for “digital twin”? In general I’m struggling to see how wot distinguishes between the actual thing and it’s twin.

... After searching and reading thru the wot projects, it seems that a TD with bindings would be defined for the physical device (akin to an edgex device service or hono’s concept of a device), and a separate TD with probably different bindings would be defined for the twin (akin to ditto’s concept of a thing).

In short, wot seems to not model concept of device vs device-twin in any concrete way. Is this understanding correct?

Thank you for your feedback. I think it might be worth opening a new issue in https://github.com/w3c/wot-architecture or https://github.com/w3c/wot since you're asking broader questions than the scope of this issue. Also there you'll reach more people.

@mmccool
Copy link
Contributor Author

mmccool commented Apr 5, 2021

I agree, this needs to be discussed in architecture or thing-description.

@mmccool
Copy link
Contributor Author

mmccool commented Aug 22, 2022

Resolved as "no" for now, but we might consider in next version, so I have marked it as deferred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants