Remove vocabulary note - closes #17

[benfrancis]

---

Preview | Diff

[mlagally]

The note is outdated and we should have replacement language that gives guidance of how to encode geolocation and hardware details (version, serial, ...)

[mlagally]

This text removes terms that were to be included into the TD spec.

This was a precondition for removing the previous section from the profile which happened about a year ago.

I just checked the geolocation case, which is very important for interoperability:
Unfortunately the TD specification does not define corresponding vocabulary terms for these values and just contains an example that references a rather old IG note.

Therefore I suggest to hold off deleting this section until we have a clear way to specify these attributes in the profile.

[mlagally]

The current text was a placeholder for specification language we expected from the TD specification.
It should be kept as a placeholder until we have appropriate replacement language, that enables to define "profile-things" that have a location and common metadata that allow
common management of these (e.g. displaying them on a map, handling hardware and software version information).

These additional fields are one of the key benefits of the profile, since they enable interesting interop scenarios, that are not possible without them.

I strongly suggest to decide on the key names and agree on a format for the values.
If we cannot agree on a single format for profile purposes, we could define an unambiguous way of indicating the interpretation of the values.

[benfrancis]

My understanding of the action from the architecture call noted on 25th November 2021 was that the decision was to just remove the note.

I don't agree with the need to extend the Thing Description data model with serialNumber, hardwareRevision, softwareRevision, loc_latitude, loc_longitude loc_altitude, loc_height, and loc_depth members inside the WoT Profile specification*. I've therefore unassigned myself from issue #17 so that if someone wants to make the case for those members they can assign themselves to the issue.

I'll close this PR since it doesn't seem to be needed.

* For discussion about an alternative approach for geolocation data, see #137.