On the meaning of si:complete

[pietercolpaert]

At this moment you have si:complete as a flag indicating if a shape index is complete, thus, every resource inside the subweb is describe by the index.

However, I wonder whether this doesn’t boil down to describing open or closed shapes, making this property redundant

[constraintAutomaton]

No, because there is a distinction between the knowledge graph (a graph of triple where the RDF subjects are the node and the predicate the edges) and the network (a graph where documents [RDF subgraph] are the nodes and the RDF terms leading towards the documents are the edges ). si:complete is in the related to the network. It says that every document inside the subweb managed by the data provider is mapped with a shape. In contrast, closed and open shapes characterize if the star patterns governed by a shape can contain more or less information than the shape definition.

[constraintAutomaton]

I guess we can say that the materialized knowledge graph in possibly multiple documents does not affect its definition in "any way". Thus, we cannot affect the data distribution through a shape. But, tell me if I am wrong.

[pietercolpaert]

I agree that indeed sh:closed cannot solve this as the domain of si:complete is the full shape index and not an individual entry.

However, I really wonder about what the actual semantics is of complete: what if the shapes in the entries are open, and you indicate it’s complete, does it really have value? If all shapes are closed, then yes, it could make sense to also close the shape index, probably. This is then also somehow is a promise by the server to keep its index always in-sync with the actual data in the subweb, as from the moment it would be out of sync it could be lying about being complete.

[constraintAutomaton]

what if the shapes in the entries are open, and you indicate it’s complete, does it really have value?

Yes, it means you can find all the IRIs of the subweb documents using the index (I am also adding an extension about how to discover IRI when it is a URI template, like with LDP, I've discussed it with Ruben T.).

This is then also somehow is a promise by the server to keep its index always in-sync with the actual data in the subweb

Yes, but our claim is that it is very easy to maintain since the shapes and location of documents in the main should not change so much, and nothing can stop you from keeping the index open if you cannot guarantee this (you have the flexibility of incomplete shape index and open shapes).

[constraintAutomaton]

But, yes it is less useful when the shapes are open, but the index as a whole is less useful that way.

[pietercolpaert]

Oh! I notice I misinterpreted complete all along! So it’s the completeness of the IRIs, not of the shapes. That should be clearer in the spec.

It also feels like you could then extend the text to any kind of hypermedia specification, no? It’s a starting point that then can be used.

Also IRI templates: don’t you then also need to explain how the variables in the template can be used, and what can be filled out in these variables? I.e. in TREE we have a couple of specific search forms for that: https://treecg.github.io/specification/#xyztiles

[constraintAutomaton]

I guess in simpler terms; it means that every document are mapped with shapes, hence you have full knowledge of at list what is the minimum content of the dataset and its general location it (will be more precise with the LDP-like extension we are working on)

[pietercolpaert]

I’m not sure what you intend to do with the LDP extension, so looking forward to seeing that

[constraintAutomaton]

Extension might have been used incorrectly in this sentence. We want to add something to the spec that would enable us to travel using URI templates like LDP. So, something very simple and really scope for that.