Add predicate to link TypeIndex to TypeRegistrations.

[woutermont]

As discussed in the meeting of today (January 17th), I repeat my last comment on #5 here, so that the PR itself can be closed.

---

We currently rely on the unspecified anti-LinkedData convention that Type Registrations will be served in the same file as the Type Index itself. I.m.o. it would be better to specify this in a Linked Data manner, by adding an extra predicate to the Type Index shapes. This way, all Type Registrations are linked to from their Type Index.

:TypeIndexShape a sh:NodeShape ;
    # ...
    sh:property [
        sh:path solid:hasTypeRegistration ;
        sh:nodeKind sh:IRI
    ] .

typeIndex:TypeIndex EXTRA a {
    # ...
    solid:hasTypeRegistration IRI .
}

---

During the meeting, we concluded that we are in favour of adding this, but we have to look into compatibility. We saw two possible options:

• Don't change the shapes now, but already mention the link predicate as a future requirement in the specification.
• Add the link predicate as optional to the shapes, and mention it as a future requirement in the specification.

[timbl]

I always prefer typeRegistration to hasTypeRegistration ... auto-generated form field names are better, not to mention te N3 form is typeRegistration of.

[timbl]

"We currently rely on the unspecified anti-LinkedData convention that Type Registrations will be served in the same file as the Type Index itself." Actually I disagree that that is anti-linked-data. Linked data is a set of documents, and what is in each document is really important. For example, the triples about me in my profile are things I vouch for, and the ones about you in your profile are ones you vouch for. Systems must not treat with the same trust any things you might say about me in your profile. The typeindex is the document in which I declare my public stuff. When you say "the same file as the Type Index itself." well teh type index is a file, that's the same thing. Soon balance I disagree with this change to add the link as it is unnecessary. You look for anything in the file which declares itself to be of rdf:type TypeRegistration. Adding this extra link gives three problems- what to do when something has the link but not the type, or vice-versa, and transitioning our code and the existing type indexes.

[woutermont]

@timbl, first of all, we already decided during the meeting that we were in favor of this; the question in this issue is about how we want to approach it.

Secondly, you point out the importance of documents, and suggest to stick with the type-based inference of relevant data. What you seem to miss/ignore is that we don't do take such an approach for almost all other data. When we want to know the Identity Provider of someone, or the Type Index itself, we look for the links solid:issuer and solid:publicTypeIndex, not for rdf:type solid:Issuer or rdf:type solid:PublicTypeIndex.

Also, two of the three problems you indicate (what to do when something has the link but not the type, or vice-versa) are not problems of this accepted change: everywhere, anytime, you can ask that question about data; in particular, you can just as well ask "what to do when something has the solid:TypeRegistration type, but not the right triples/attributes." Maintaining data quality is something we do using shapes, and the question of this issue is precisely how we want to introduce the solid:typeRegistration relation in there. The option we agree on will then also be the answer to you third problem.

[josephguillaume]

Also see discussion at #29