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

Define the WoT-Directory type somewhere (eg in new version of context, in 1.1) #43

Closed
mmccool opened this issue Aug 3, 2020 · 7 comments

Comments

@mmccool
Copy link
Contributor

mmccool commented Aug 3, 2020

Could put in the v1.1 context file. Should probably be just "Directory".

@relu91
Copy link
Member

relu91 commented Jan 18, 2021

I think we should consider if in the future TDD related terms will grow. Considering that we are also defining a data model for TD stored in directories (see issue #98) we could define our context without filling the Thing Description context file with unrelated stuff.

@mmccool
Copy link
Contributor Author

mmccool commented Jan 18, 2021

To recap discussion:

  • We need to quickly determine during introduction whether a link points at a Thing or a Directory
  • We could use a special context file for this, but I think an @type is more direct and clearer
  • We could always define the Directory @type in a context file for directories, and use a prefix to avoid any possibility of name conflicts (e.g. dir:Directory).
  • We need a context file anyway...

@farshidtz
Copy link
Member

DirectoryDescription type has been added to a local discovery context: https://github.com/w3c/wot-discovery/blob/main/context/discovery-context.jsonld

@benfrancis
Copy link
Member

From #133

Why does a description of a thing have a @type of Thing, but a description of a directory has a @type of DirectoryDescription? Surely it should either be ThingDescription & DirectoryDescription or Thing & Directory for consistency?

@farshidtz farshidtz reopened this Mar 26, 2021
@farshidtz
Copy link
Member

It seems that the TD 1.0 spec uses @type to refer to the actual entities, rather than the description of it. For example:

  • Thing
  • saref:LightSwitch
  • saref:TemperatureSensor

Following that, it makes sense to also use Directory type (instead of DirectoryDescription).

I think there were two reasons for choosing DirectoryDescription (@AndreaCimminoArriaga please correct me if i'm wrong):

  1. We wanted to reserve Directory for referring to the directory itself in the ontology. I now think it is okay to reuse the actual thing's type as TD type since it is a common practice. But we should check the spec and ontology to make sure this change doesn't add confusion.
  2. We wanted to make it consistent with LinkDescription. As mentioned in Add links section to directory information model #34 (comment), we can't use Link, since TD already uses that.

But there is a new addition in TD 1.1:

  • ThingModel which can be combined with other types. This one makes less sense to me: it is not a model of an actual entity. "A Thing Model is a template for Thing Descriptions". Previously called: Thing Description Template.

If Thing refers to Thing Description, then the discovery types could be ThingDirectory and ThingLink!

Maybe @sebastiankb, @vcharpenay, @egekorkan, or @mmccool could clarify.

@AndreaCimminoArriaga
Copy link
Contributor

Correct @farshidtz. One of the reasons was also because we were mixing pagination information with TDs so we had to distinguish what a Directory was (that had such pagination information), and what Directory Descriptions were (stored Thing referring to directories). Nevertheless, now that the pagination is not mixing information I think we could evolve the types names. I like the idea of changing the names to ThingDirectory and ThingLink.

@farshidtz
Copy link
Member

The type has been changed to ThingDirectory, in the discovery context: https://github.com/w3c/wot-discovery/blob/main/context/discovery-context.jsonld

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

5 participants