Change to the JSON-LD Structure of the Standard to support Startin' Blox integrating

[RaggedStaff]

Further to this discussion in slack, Startin' Blox (SIB) are proposing a couple of changes/clarifications to the format of the JSONLD within DFC standard.

1. Context link: SIB would prefer a direct URL without link in the header. Could the DFC Wordpress site maybe return the context directly if asked for JSON format?
2. SIB assume to see only one object per resource instead of a graph.
3. SIB work with ldp:contains instead of arrays for collections.

Further details are available on the SIB API Guidelines

[RaggedStaff]

Context link: SIB would prefer a direct URL without link in the header. Could the DFC Wordpress site maybe return the context directly if asked for JSON format?

I think this is actually a wider issue... the current URI's for the ontology/taxonomies return a download link, there is no direct URL access to the ontology files. @lecoqlibre : Can you confirm how this is expected to work?

SIB assume to see only one object per resource instead of a graph.

I think this would primarily impact the bulk GET of Products, there would probably be impacts to the Prototype code and other platforms would need to update their code to comply with this change. It may be possible to absorb some/all of the change within the connector (for platforms utilising that). @lecoqlibre : what do you think ?

SIB work with ldp:contains instead of arrays for collections.

I think this makes sense & my only concern is whether this move us closer to general SOLID compliance or is this a practice specific to Startin' Blox ?

[lecoqlibre]

1. JSON-LD context

Following the link in the header will lead to the direct URL: https://www.datafoodconsortium.org/wp-content/plugins/wordpress-context-jsonld/context.jsonld (with a content-type: application/ld+json header).

I already told Benoit and the direct link is written in the SiB API Guidelines.

About the ontologies and taxonomies I guess we will have a problem if we try to do inference. Sooner or later we will probably have to provide direct links. But if we are just referencing vocabularies it should not be a problem.

2. One object per resource instead of a graph

In the SiB API Guidelines I can read:

We do not use named graphs (i.e. the @graph: [] syntax), but limit the content of a given URI to one resource only using plain resource representation instead, with access to every resource triples (both properties and relations to other resources).

I'm very afraid to see that because one of the top requirements of Solid is the support of documents which can contain multiple objects!

DFC is using default graph (a graph with no name) which is an easy way to represent documents. This is illustrated on the example 116 of the JSON-LD spec.

The JSON-LD spec says:

When a JSON-LD document's top-level structure is a map that contains no other keys than @graph and optionally @context (properties that are not mapped to an IRI or a keyword are ignored), @graph is considered to express the otherwise implicit default graph. This mechanism can be useful when a number of nodes exist at the document's top level that share the same context, which is, e.g., the case when a document is flattened. The @graph keyword collects such nodes in an array and allows the use of a shared context.

If we don't use the @graph we would be forced to unprefix everything or duplicate the @context like on the example 117.

I made some tests to access the representation of a document in JSON-LD on both:

• Community Solid Server: it serves a unprefixed array of objects;
• Node Solid Server: it does serve a map with a @context and a @graph (like DFC does).

3. Use ldp:contains instead of arrays for collections

This is two different things. ldp:contains is used to describe a LDP container, not a collection of values.

But whatever, the standard should not tell where to host the data. It should instead let users choose the locations they want, in LDP containers or not, with one or multiple objects per document. This is also a top requirement of Solid!

The standard should therefore instead provide a way to express the locations chosen by users. It might recommend various file structures to fit the users needs and ensure scalability.

The current DFC Solid client-to-client standard proposes to use a TypeIndex [1] to save these locations. A discussion on this subject is started here. This would require the ability to serve a profile document associated to the user's WebID (which SiB does not support yet).

Conclusion

In conclusion I would say that we need to agree on a way to express data locations in the DFC standard. For me we should use an index document (TypeIndex or not) as it is pure RDF which ensure consistency and re-usability. This index would contain pointers to documents or LDP containers, depending on users needs.

Also I would say that SiB should comply with the Solid spec and thus support documents and WebID.

[1] I'm wondering if it would not be better to use a dedicated index instead. Indeed, like Tim B. Lee told us, the TypeIndex should be used for large piece of data only. I would like to talk with the TypeIndex team about it. But even if we don't use a Typeindex this won't change a lot a thing as we still need to be able to save the location to this index somewhere, in the profile document or elsewhere.

[mkllnk]

I'm trying to summarise my understanding of your reply here.

JSON-LD context

We just use the direct long link as context and we are good.

One object per resource instead of a graph

You would like Startin'Blox to support the @graph structure.

I don't think that Startin'Blox supports the unprefixed array either. They just want one object on the top level, not multiple. Since this is very restrictive and Solid supports multiple objects, Startin'Blox should increase compatibility and support @graph, right?

Use ldp:contains instead of arrays for collections

I don't understand the details here.

Using ldp:contains for every collection means that every collection has an id (URL) and can be referenced. So as long as we have one entry point, like the link to a person, an enterprise or a collection, we can find all other related data from there. A container can be hosted anywhere. So I can have a user profile on serverA and it says that I manage products in a container on serverB. I don't understand why we need TypeIndex in this case. The addition of containers introduces some indirection to the data structure though. Instead of enterprise manages product we have to write enterprise manages container which contains product. Is that right?

[lecoqlibre]

A container can be hosted anywhere. So I can have a user profile on serverA and it says that I manage products in a container on serverB. I don't understand why we need TypeIndex in this case.

Providing such links in the user's profile is like a kind of index or a kind of indexing strategy. TypeIndex can be used as an indexing strategy. We will have to choose how we want to express these links.

I plan to publish a proposal using WebID profile soon in the Data Discovery discussion.

[balessan]

So, Benoit from Startin'blox here. I would like to clarify that the document we write do not bear the intention to be accepted as-is as modifications to the DFC standard, but provides an explanation of our own APIs constraints to ease the technical convergence work.

1. JSON-LD context

Managed as stated by @mkllnk by We just use the direct long link as context and we are good.

2. One object per resource instead of a graph
   I'm very afraid to see that because one of the top requirements of Solid is the support of documents which can contain multiple objects!

I am not sure where you get that exact requirements being part of Solid. As we are actually discussing as part of our common project it looks more of a client-to-client agreement on the graph structure of your hierarchy of documents. We may have missed something from the specs though.

@lecoqlibre let's put that on the roadmap of our client framework improvements then.

3. Use ldp:contains instead of arrays for collections
   But whatever, the standard should not tell where to host the data. It should instead let users choose the locations they want, in LDP > containers or not, with one or multiple objects per document. This is also a top requirement of Solid!

I do not get how you can push to promote the client-to-client standard approach and then state that users/apps should do what they want. In a practical implementation in the real world where none of the WebID or TypeIndex or others current drafts are widely used, we need to enforce constraints on those questions to achieve some interoperability.

You have to understand that the massive usage of containers on SiB side is the current implementation achieving this goal without requiring any type of Index which we started before those topics were raised.

Once again, let's use the context of our common research project to converge.

Also I would say that SiB should comply with the Solid spec and thus support documents and WebID.

As far as I know, we support Solid-OIDC, LDP, Web-ACLs and Linked data Notifications. Simplifying the conclusion as "you should comply" to a specification which is still a draft covering really wide ambitions (I mean, Web-sized ambitions is wide) does not look constructive. As a reminder, even the CSS does not support ACP or Linked Data Event Streams or the WebSocket part of the specs. Do you consider it compliant though ?

[lecoqlibre]

in the real world where none of the WebID or TypeIndex or others current drafts are widely used

Solid-OIDC relies on WebID and both are part of the Solid client-to-server spec. So WebID must be implemented by Solid compliant servers and apps.

TypeIndex is part of the client-to-client part of Solid and is mentioned as a possibility in the Solid WebID Profile spec: "This document can contain references to [...] Type Index Documents." (source). So this could be ignored in implementations.

[lecoqlibre]

You have to understand that the massive usage of containers on SiB side is the current implementation achieving this goal without requiring any type of Index which we started before those topics were raised.

If you don't have a data discovery mechanism it certainly means that you know where to find these containers. If so, you have defined a kind of client-to-client standard but without naming it.

[lecoqlibre]

As far as I know, we support Solid-OIDC, LDP, Web-ACLs and Linked data Notifications. Simplifying the conclusion as "you should comply" to a specification which is still a draft covering really wide ambitions

I was referring to WebID and the architecture document.

Be aware that SiB LDP support is not totally correct as you don't support Turtle yet. For instance, section 4.3.2.1 is normative and says that: "LDP servers MUST respond with a Turtle representation of the requested LDP-RS when the request includes an Accept header specifying text/turtle, unless HTTP content negotiation requires a different outcome [turtle]".

[lecoqlibre]

the CSS does not support ACP or Linked Data Event Streams or the WebSocket part of the specs. Do you consider it compliant though ?

I did not check these parts are mandatory but I'm sure it's not the case for ACP as the section 11. Authorization states: "Servers MUST conform to either or both Web Access Control [WAC] and Access Control Policy [ACP] specifications".

[lecoqlibre]

let's put that on the roadmap of our client framework improvements then.

Yes! 💯

[mkllnk]

Since this work is being picked up again, I just wanted to add a vague memory that the Startin'Blox framework would like all linked resources in JSON format. I think @balessan mentioned that a dependency update will remove support of referencing RDF files in the context. Is that right?