Vocabulary not in TD context

[sebastiankb]

Section 4.1.2.2 list a number of vocabulary (e.g., softwareRevision, loc_latitude,...) that are not mention in the TD specification yet.

Is there an intention to define a new context file that defines these terms or do you refer to existing ontologies that use these terms?

[mlagally]

Discussion on call on 23.7.:
Intention is not to diverge from the TD spec or define duplicate entities or to fragment.

Section 4.1.2.2 list a number of vocabulary (e.g., softwareRevision, loc_latitude,...) that are not mention in the TD specification yet.
https://w3c.github.io/wot-profile/#recommended-practice- section 4.1.2.2 of wot-profile draft
sk: this is listed for the core profile
... but no new term is clearly defined
ml: we have practical knowledge based on our PlugFest efforts
... but the knowledge requires some baseline for interoperability

Regarding the terminology definition itself, we can start with listing undefined terms with "to be defined" :)
These can be listed here and moved to the architecture spec at a later time.

[mlagally]

Discussion on 2nd call:
Using a different ontology file than the TD would no longer be a TD.
Adding an extension vocabulary would still be a subset.
We should limit the extensions to the minimum.
We should start with the main ontology.
New metadata fields can start in the Profile spec and be pushed up to the TD.

We should not fragment - a profile TD is still a TD.
We might define a limited frozen set of extension vocabulary.

[sebastiankb]

My proposal would be to focus on the vocabularies that currently exist in the TD model and use them in the FPWD. We should bring the list of desired vocabularies (https://w3c.github.io/wot-profile/#recommended-practice-) to the TD TF which should evaluate and take care that the right context is defined for that terms. Maybe in one of the next iteration we can introduce this new terms in the Profile document.

@mlagally If ok, I can setup PR for this.

[benfrancis]

There is a note about this in 5.1.2.2 Recommended practice.

I propose that this note removed (it should have been an editor's note) and that these additional members not be added to the Thing Description.

[benfrancis]

Action from architecture call: remove note

[benfrancis]

See #149 (comment)

[mlagally]

Arch call on May 4th:
Consider to define a context file with a prefix for the profile.

[mlagally]

I think we have to circle back on this.

Geolocation is very important for many use cases, and interoperability via a profile adds real value.

Two years ago we proposed keywords for geolocation, hardware serial number and similar very reasonable metadata fields.
These were then taken over to the TD TF with the expectation that they would be defined there.

Unfortunately this did not happen, so I suggest we proceed with the original path and define them in the profile via a context extension.

[egekorkan]

They are already defined in places like schema.org and other ontologies so we do no have to define them ourselves. You can however mandate the usage of these annotations

[mlagally]

@egekorkan I agree, in past discussions we considered adding normative references to these ontologies.
We also discussed a priority order at that time, we should select the ontologies first and then discuss the order.

[benfrancis]

In general I think it's better to avoid adding terms to the TD Information Model in a profile which aren't in the Thing Description specification, because a Consumer which doesn't implement the profile won't recognise those terms. If there really is something missing from the TD Information Model which isn't defined anywhere else then it should be added to the Thing Description specification.

I agree it would be reasonable (and would aid interoperability) for a profile to recommend or require that conformant Things use certain ontologies for certain common terms using semantic annotations, a good example being geolocation for which schema.org defines a GeoCoordinates type (including longitude, latitude and elevation), which is used in Example 46 of the Thing Description specification.

Note that schema.org also defines a serialNumber type, which is used in Example 43 in the Thing Description specification.

How about we add a "Semantic Annotations" section to the HTTP Baseline Profile which recommends ontologies for certain common terms like geolocation (#137) and units (#29)?

I can draft something, but it will require us agreeing on which ontologies to recommend.

We may also need to agree on where those annotations can be used within the Thing Description, e.g. as an interaction affordance:

{
    "@context": [
        "https://www.w3.org/2022/wot/td/v1.1",
        {
            "schema": "http://schema.org#"
        }
    ],
    "properties": {
        "position": {
            "type": "object",
            "@type": "schema:GeoCoordinates",
            "properties": {
                    "longitude": { "type": "number" },
                    "latitude":  { "type": "number" },
                    "elevation": { "type": "number" }
            }
        },
    },
}

vs. a top level member:

{
    "@context": [
        "https://www.w3.org/2022/wot/td/v1.1",
        {
            "schema": "http://schema.org#"
        }
    ],
    "schema:longitude": "297.83",
    "schema:latitude": "26.58",
    "schema:elevation": "5.3"
}

[mlagally]

@benfrancis
Thanks a lot for this elaborate proposal with these examples, which addresses the requirements for location information.
I prefer the second form, since it is more descriptive and more flexible - you could have a thing where the position changes and you get event notifications when that happens.

How about we add a "Semantic Annotations" section to the HTTP Baseline Profile which recommends ontologies for certain common terms like geolocation (#137) and units (#29)?

We should definitely do that, however it should be a common section that applies for all profiles in the Profile 1.0 spec.
We had discussed this some time in the past already and had a proposal by Michael for units.

[benfrancis]

I prefer the second form, since it is more descriptive and more flexible - you could have a thing where the position changes and you get event notifications when that happens.

Actually if the location is likely to change you probably want it to be a property you can observe (as in the first example), rather than statically defined at the top level of the Thing Description (as in the second example).

I would be fine with allowing both.

(I'm not actually sure whether it's valid to use a schema.org property outside of a schema.org typed object, but the Thing Description 1.1 specification already has examples which do that. I've asked for clarification.)

What was the proposal for units? See also: #29 (comment).