Member id could not be extracted from model

[xdxxxdx]

Prerequisites:

1. Docker image version: Snapshot 2.7.0
2. The view nodes are configured on the server by posting the following configuration:

@prefix ldes: <https://w3id.org/ldes#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix tree: <https://w3id.org/tree#>.
@prefix sh:   <http://www.w3.org/ns/shacl#> .
@prefix server: <http://localhost:8080/> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix nodes: <http://localhost:8080/nodes/> .

server:nodes a ldes:EventStream ;
	ldes:timestampPath dcterms:created ;
	ldes:versionOfPath dcterms:isVersionOf ;
	tree:shape nodes:shape .

nodes:shape a sh:NodeShape ;
	sh:targetClass <https://vocabulary.uncefact.org/LogisticsLocation> 

I tested sh:targetClass is no longer a mandatory filed for creating eventstream, I put it here still somehow for demonstrating purpose.

3. Configure a pagination view by post

@prefix tree:   <https://w3id.org/tree#>.
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .
@prefix ldes:   <https://w3id.org/ldes#> .
@prefix prov:   <http://www.w3.org/ns/prov#> .

</nodes/paged> a tree:Node ;
  tree:viewDescription [
    a tree:ViewDescription ;
    tree:fragmentationStrategy  () ;
    ldes:retentionPolicy [
      a ldes:LatestVersionSubset ;
      ldes:amount 1 ;
    ] ;
    tree:pageSize "10"^^<http://www.w3.org/2001/XMLSchema#int> ;
] .

Scenarios

1. Post following member to the nodes stream

@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix ns0: <https://schema.org/> .
@prefix ns1: <https://vocabulary.uncefact.org/> .

<http://example.org/node/id/1/2>
  a <https://vocabulary.uncefact.org/LogisticsLocation> ;
  dc:isVersionOf "http://example.org/node/id/1"^^xsd:string ;
  prov:generatedAtTime "2021-05-20T10:00:00Z"^^xsd:dateTime ;
  ns0:latitude 5.236760e+1 ;
  ns0:longitude 4.904100e+0 ;
  ns1:name "k1700"^^xsd:string ;
  ns1:servicingSpecifiedParty ns1:servicingSpecifiedParty1 .

ns1:servicingSpecifiedParty1
  a ns1:LocationParty ;
  dc:isVersionOf "http://example.org/node/party/1"^^xsd:string ;
  ns1:name "DP-World"^^xsd:string .

Current behavior

Member id could not be extracted from model: 

@prefix dc:   <http://purl.org/dc/terms/> .
@prefix ns0:  <https://schema.org/> .
@prefix ns1:  <https://vocabulary.uncefact.org/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

ns1:servicingSpecifiedParty1
        a               ns1:LocationParty ;
        dc:isVersionOf  "http://example.org/node/party/1" ;
        ns1:name        "DP-World" .

<http://example.org/node/id/1/2>
        a                            ns1:LogisticsLocation ;
        dc:isVersionOf               "http://example.org/node/id/1" ;
        prov:generatedAtTime         "2021-05-20T10:00:00Z"^^xsd:dateTime ;
        ns0:latitude                 5.236760e+1 ;
        ns0:longitude                4.904100e+0 ;
        ns1:name                     "k1700" ;
        ns1:servicingSpecifiedParty  ns1:servicingSpecifiedParty1 .

I understand now the member identity is retrieved by the dc:isVersionOf ontology for enabling mixed member types to the same stream.
I am just wondering how we can avoid several dc:isVersionOf used in one member, especially the member can be embedded with several entities and blank nodes, in the example case: ns1:servicingSpecifiedParty1 inside <http://example.org/node/id/1/2>

Thanks

[rorlic]

Short term answer:
your member contains in fact multiple members and we do not (yet) support bulk ingest.

In addition, the object of the dc:isVersionOf is a string and not a named node
dc:isVersionOf "http://example.org/node/id/1"^^xsd:string ; should be
dc:isVersionOf <http://example.org/node/id/1> ;

Unrelated: you can define the server prefix in the LDES definition as follows:

@prefix server: </> .

Long term answer:
If and when we add member creation (state object to version object) in the server we can add bullk ingest. For now, you need to ingest each member separately.

[xdxxxdx]

Short term answer: your member contains in fact multiple members and we do not (yet) support bulk ingest.

In addition, the object of the dc:isVersionOf is a string and not a named node dc:isVersionOf "http://example.org/node/id/1"^^xsd:string ; should be dc:isVersionOf <http://example.org/node/id/1> ;

Unrelated: you can define the server prefix in the LDES definition as follows:

@prefix server: </> .

Long term answer: If and when we add member creation (state object to version object) in the server we can add bullk ingest. For now, you need to ingest each member separately.

Thanks for the reply @rorlic yes, you are right.

I am just wondering how we can handle that when the member has several entities mixed inside.
I am not aiming to ingest several members. But, we never can make sure the data source for ingesting doesn't contain dc:isVersionOf already inside (even if we move version creation into the server).
In the end, there always might be node(s) embedded in a member with unexpected dc:isVersionOf inside then we can have more than one dc:isVersionOf with different entities as objects.

I don't have an answer for this either, maybe a SHACL run before ingestion to make sure there is no dc:isVersionOf existing already?
I feel maybe it is worth considering about it.
Thanks

[rorlic]

Yes, shacl validation may prevent this but comes at a performance cost.

I agree that during the development or testing of a LDES creation you may bump into this but as a data owner/publisher you are responsible to ensure your data is correct (garbage in-out). If you try to ingest an unparseable member the ingest will fail too. The only difference is a semantical error vs. a syntactical error.

Later, when creating versions in the server and allowing bulk ingest we can be more forgiving but if you try to ingest a member (i.e. a version object) we'll need to fail as we'll be expecting state objects then. Not?

The only thing we can do today is add a clearer message why we cannot ingest the message.

[xdxxxdx]

Later, when creating versions in the server and allowing bulk ingest we can be more forgiving but if you try to ingest a member (i.e. a version object) we'll need to fail as we'll be expecting state objects then. Not?

That makes sense to me. For the final products of LDES Server, we can say that we are only expecting a state object, also the entity will be split.