Fix #139: Member extraction algorithm

[pietercolpaert]

What we’ve done:

• Introduced the TREE MEA vs. the Generalized MEA with the shape topology algorithm
• Introduced the property tree:shapeTopology on a root node to indicate that the shape topology algorithm must be used. Otherwise, the TREE MEA can be used
• Added a link to the Profile Algorithm in the spec
• Minor: cleaned up the prefixes in the vocabulary
• Added support for triple terms for when RDF1.2 would land
• Added support for context associations: when a blank node is encountered, also the quads in that named graph are added to the set of quads in the member.

Issue to be discussed as proposed by @smessie: when dereferencing a page, do we include all quads on that page in the member, or do we (as we have done it so far) re-execute the MEA on that response?

PREVIEW

[smessie]

Issue to be discussed as proposed by @smessie: when dereferencing a page, do we include all quads on that page in the member, or do we (as we have done it so far) re-execute the MEA on that response?

The reasoning for this is as follows:
In a graph-centric approach where we question ourselves how to handle named graphs, we reasoned that if f appears as the IRI of a named graph in G, it is reasonable to treat all quads in that graph as intentionally associated with f.
This thus explicitly binds the data to a specific member, preventing its inclusion in others, but thus also allows other triples — going beyond subject-based star patterns complexity — to be included in the set of triples belonging to the member.
In the exact same way, I want to propose following this behavior for the more document-centric approach like a Container/Resource-based system; if f appears as the IRI of a resource, it is reasonable to treat all quads in that resource as intentionally associated with f.
Or in other words, just like we reasoned for named graphs that all triples in that graph f should belong to M, we should also reason that all quads in a resource f should belong to M.
In the same way, this allows us to include quads going beyond the subject-based star patterns complexity to be included in the set of quads belonging to the member.
Moreover, this will also give us compatibility with how LDP works: ldp:contains can be seen as the containment triple, and then the member is the associated resource, with all quads in that resource being the set of quads for that member.

[pietercolpaert]

Actually, that would indeed make it similar to how ldp:contains works, but also ldp:member exists. ldp:member in that sense is much closer to how tree:member works today, in which multiple members can be described into a resource contained in a container.

I thus see your line of argumentation as arguments that could work to back up both cases. I’m happy to follow the majority here though, although if we change this, it’s technically a backwards-incompatible change (although I don’t think there are more than 1 implementations of this at this moment).

[smessie]

Note that my last sentence on ldp:contains was just an example, even though, to my feeling ldp:contains is way more common than ldp:member.
This while my main point of argument is the alignment between how we handle named graphs and how we handle resources. These can be very well aligned, and I see no reason — to the contrary — why not to do so.

[pietercolpaert]

I’m leaning towards not merging this as-is, and instead make the member extraction algorithm a minor paragraph in the spec that refers to a separate document that is non-normative. More specific clients and ecosystems will decide for themselves how to do the member extraction. I.e. in LDES, they are now constraining the members to named-graph and CBD-based.