TS-0004 Issues with <SemanticFanOutPoint>
-
Clause 7.4.35 says that a SemanticFanOutPoint
is the child resource of a <group> resource.
but according to TS-0001 it only exists if the Group's members are of type<semanticDescriptor> or <contentInstance>
. There is nothing that says that in 7.4.35 or in the clause on<group>
(7.4.13). -
The Clause then goes on to say:
A <semanticFanOutPoint> can be addressed in one of two ways:
• Using the URI retrieved from its parent <group> resource; or
• Using a hierarchical URI formed by taking the hierarchical URI of the parent <group> and appending the string /sfop to that URI
I can't see a way to retrieve its URI from the parent resource, other than appending /sfop.
- Clause 7.4.35.2.2 step 3 says
Fan-out <semanticDescriptor> Retrieve Requests to each CSE hosting sub-groups or members
- I can see how you can fan out a
<semanticDescriptor>
Retrieve request in the case where the parent group is comprised of just<semanticDescriptor>
members, but what if it has<contentInstance>
members - TS-0001 doesn't mention groups with sub-groups having semanticFanOutPoints.
-
Clause 7.4.35.2.2 step 3a) includes the text:
The prefix of primitive parameter To i.e. <URI of group resource>/sfop shall be replaced by hierarchical URIs derived from the attribute memberIDs of the <group> resource.
This is hard to follow. Why doesn't it just use the memberIds (adding /sfop if the members are sub-groups)? -
Clause 7.4.35.2.2.step 3b includes the text:
The group-hosting CSE shall execute "Compose Request primitives" with the semanticsFilter filter condition set to false.
The semanticsFilter condition is a SPARQL query. Does it make sense to describe it as being “set to false”? Should this instead say that the group-hosting CSE omits the semanticsFilter from the requests?