[TD-TF] avoiding using an array for names that are supposed to be unique

[draggett]

If the names for properties are supposed to be unique then it makes sense to use the object notation rather than an array, and likewise for actions and events. For instance:

   "properties": {
       "foo" : {
                // place the metadata for property foo here
           }
       "bar" : {
                // place the metadata for property bar here
       }
   }

[vcharpenay]

In theory, it would be a good idea. However, this does not work well with JSON-LD. More precisely, the RDF data you would get by transforming this object into RDF (from the JSON-LD API specification) would not be valid.

What is more, I'm not sure using name as an ID is a good idea. To me, it was rather meant to be a human-readable label for the object (like "My kitchen temperature sensor"). I would say JSON-LD's @id is a better choice.

So, having something like this would be much more JSON-LD-friendly and uniqueness is still guaranteed:

"properties": [
  {
    "@id": "foo",
    // place the metadata for property foo here
  },
  {
    "@id": "bar",
    // place the metadata for property bar here
  }
]

[draggett]

I've checked with people outside of the WoT IG and they aren't so concerned about precisely following the JSON-LD specification. We would need to define how to transform to RDF, but that is easy with a small number of rules. To put it another way, ease of reading and conciseness for web developers are more important than sticking to the letter of the current JSON-LD specification.

[maximelefrancois86]

I believe Dave's use of term property means in this context "property key", or RDF property. Not Thing property. Or is it ?

Anyways, that's an interesting question you raise here Dave, I think it should be discussed further, maybe during the meeting next week.

I see the following advantages in proposing just a pure JSON syntax for Thing Descriptions, along with simple rules to transform a thing description to RDF,

• it is very probable that the JSON thing description will lighter than if we stick to JSON-LD, and moreover more natural to web developers;
• it will be a relief for Semantic Web members of the group to not having to manage in parallel:
  • the specification of the WoT ontology;
  • the maintenance of a JSON-LD context in parallel; and
  • to ensure any JSON thing description is indeed be properly interpreted as RDF conforming to the WoT ontology.
• one may go further and define one JSON Schemas that Thing Descriptions should validate against, Although this might prevent the extensibility of thing descriptions, it would surely ease the support of Thing Descriptions in constrained devices;
• there exists several formalisms one may use to define the interpretation of a JSON document as RDF, among other RML, XSPARQL, SPARQL-Generate;
• there exists at least one formalism one may use to generate a JSON document from RDF, STTL, aka SPARQL-Template.

One of our current research topic is actually precisely to define such equivalences between an ad-hoc format (e.g., the Thing Description in JSON), and RDF. Our proposal is called RDF Presentation and RDF Presentation negotiation, you may want to check out: https://w3id.org/rdfp/

I think this is sufficiently important a question to open a dedicated issue.

[danbri]

If you think you need something that is "nearly but not quite JSON-LD", it might be of interest that the JSON-LD community group have just started investigating possible updates/revisions to propose for W3C's official specs. See https://lists.w3.org/Archives/Public/public-vocabs/2016Oct/0001.html or chat with @gkellogg.

/cc schemaorg/schemaorg#1272

[draggett]

Thanks for the pointer. My aim here is to ensure that the WoT WG satisfies the needs of Web developers, so it is important to consider a range of choices and to find effective ways to seek feedback from developers to guide the WG on those choices. The JSON-LD Community Group should be able to help with that.

[gkellogg]

@draggett Features we're looking at for JSON-LD 1.1 CG release are highlighted on GitHub. Anything not covered there can be discussed on the mailing list, or by creating a new issue on the issue tracker. No timeframe yet.

[sebastiankb]

I do not really see the need to go away from the standardized JSON-LD and define a new n+1 approach. Actually, we have been using JSON-LD for about one year in the WoT plugfests and there were no complaints about it or any cases that make its usage not possible for any WoT application.

I prefer the way as Dan and Gregg pointed out that we can provide some inputs for the next JSON-LD version to make it perfectly fit for the Thing Description.

[danbri]

BTW while @gkellogg is here --- as I mentioned in some WoT discussions at TPAC, for IoT/WoT scenarios we'll need to bear in mind JSON-LD's use of remote context files in any security/privacy analysis. Although it is possible to use JSON-LD more verbosely without these, or by pre-caching known contexts, having devices fetch context definitions could be a potential mechanism for information leakage or surveillance risk. But that's offtopic for #259 I'm sure. There are also many IoT/WoT situations where it is important that a system continues to function reliably (perhaps with reduced functionality) without general network access. In a Web platform / browser environment the ServiceWorker and foreign fetch APIs are relevant to that problem; for WoT, I'm not sure the best approach.

[vcharpenay]

Thanks for the information! @gkellogg: I added an issue (json-ld/json-ld.org#430) that relates to our discussion here.

In essence, the problem is that there are way more JSON constructs on the Web like the one Dave proposed (object map, indexed by name) than what I suggested (array of objects with an @id), which makes translation into RDF slightly limited with the current JSON-LD specification.

[gkellogg]

@vcharpenay As I commented on that issue, we'll definitely look into it for 1.1. Thanks!

[sebastiankb]

@gkellogg In last Thing Description web meeting we spoke about the plans about JSON-LD 1.1. I’m wondering if it is possible for you to attend the next Thing Description web meeting on Wednesday (9-10:30am CEST). That would be a good opportunity to give us more details about the plan of JSON-LD 1.1 and to have a common discussion about the impact regarding the Thing Description. Please give me a short hint I will provide you the web meeting details.

[gkellogg]

@sebastiankb As I responded privately, I'm unavailable this week, but would be happy to join you another time.

[takuki]

Hi, I think the proposed use of object would make the syntax more intuitive. I would also like to point out that reading and writing the description makes no guarantee as to preserving the order among the properties. I would not like to very much when the system changes the order of property definitions. This is a characteristic of JSON. In several cases like this, I had to turn to arrays even when objects seem more appropriate.

[draggett]

@takuki could you please expand on why you think the source representation order of properties makes a difference to applications? Do you have any use cases in mind?

[vcharpenay]

To re-open the discussion about JSON-LD, I've been told by @pchampin that it is possible to extend a JSON-LD processor using the processingMode option. The default value for this option is "json-ld-1.0".

Regardless of the final shape of the TD, one solution to provide a mapping to RDF could be to specify a variant of the existing JSON-LD processor (with minimal change) that has a distinct processing mode (something like "wot-td-1.0").

[gkellogg]

Regardless of the final shape of the TD, one solution to provide a mapping to RDF could be to specify a variant of the existing JSON-LD processor (with minimal change) that has a distinct processing mode (something like "wot-td-1.0").

I'd rather get this into CG drafts and call it json-ld-1.1. TD can include the delta description within the TD spec and include the same processing mode identifier.

[egekorkan]

Given that we are not using arrays and also JSON LD 1.1, this issue can be closed.