Data model for third-party metadata on Collections and Objects

[mielvds]

As discussed in today's status meeting (9/02/22), we need a way to model metadata added by the Borrower to the Loan Collection of the Lender. The main question was wether a new resource should be created that somehow links back to the original resource and if so, with which vocabulary this construct should be described.

Example Scenario:

• The Borrower B borrows Collection X from Lender L.
• The metadata of X is stored in the data pod of L and contains a description D1.
• The metadata of X is now visible in Solid CRS of B.
• B decides to add its own description D2 of X.
• D2 is stored in the data pod of L D2 is stored in the data pod of B
• B notifies L of D2
• D2 is now visible in Solid CRS of L
  How do you represent D1 and D2 in RDF so that you can 1) tell them apart and 2) tell who the source is?

There are a few routes we can take and it largely depends on what we consider "a loan collection at the side of the borrower" to be. I'm deliberately cutting some corners here so the examples don't become too complex.

Using RDF reification and provenance

There is only one collection X and D1 and D2 are both descriptions. Reification is used to describe the provencance of D1 and D2.

<X> schema:description "D1". # from L
<X> schema:description "D2". # from B

_:1 rdf:type rdf:Statement ;
      rdf:subject <X>; 
      rdf:predicate schema:description; 
      rdf:object "D1";
      schema:created   "2022-01-16T01:52:02Z"^^xsd:dateTime;
      schema:author <L>.

_:2 rdf:type rdf:Statement ;
      rdf:subject <X>; 
      rdf:predicate schema:description; 
      rdf:object "D2";
      schema:created   "2022-01-20T01:52:02Z"^^xsd:dateTime;
      schema:author <B>.

Using RDF-star and provenance

There is only one collection X and D1 and D2 are both descriptions. RDFstar is used to describe the provenance of D1 and D2.

<X> schema:description "D1" {|
      schema:created   "2022-01-16T01:52:02Z"^^xsd:dateTime;
      schema:author <L>.
|}. # from L

<X> schema:description "D2" {|
      schema:created   "2022-01-20T01:52:02Z"^^xsd:dateTime;
      schema:author <B>.
|}. # from B

We need to be careful though, because if we would encounter cases where both triples would be the same, we wouldn't be able to tell which date goes with which author (triples are unique in rdf-star). So a safer option is:

<<X> schema:description "D1" > {| :occurence [
      schema:created   "2022-01-16T01:52:02Z"^^xsd:dateTime;
      schema:author <L>.
|}

<<X> schema:description "D2" >{| :occurence [
      schema:created   "2022-01-16T01:52:02Z"^^xsd:dateTime;
      schema:author <B>.
]
|}

Using n-ary relationships / schema:Role

An n-ary relationship goes beyond the standard binary relationship in RDF, ie. adding additional attributes describing a relation, such as when somebody president of USA. In RDF, you can do this by adding an extra node.

<X> :has_description [ a :Description; :description_value "D1"; schema:author <L> ]
<X> :has_description [ a :Description; :description_value "D2"; schema:author <B> ]

RDF has a predicate for describing structured values in this manner:

<X> schema:description [ rdf:value "D1"; schema:author <L> ]
<X> schema:description [ rdf:value "D2"; schema:author <B> ]

Schema.org has its own construct Role, mainly to specify what in what role somebody contributed to a work, but you can make it work for this use case:

<X> schema:description [ schema:description "D1"; schema:author <L> ]
<X> schema:description [ schema:description"D2"; schema:author <B> ]

Using events

An event is a new resource that can relate one resource to another one. Collection X would be two different resources: one for Lender L and one for Borrower B. This is the approach that Prov-O and Web Annotation use.

<X> schema:description "D1". # from L
<Y> schema:description "D2". # from B

<lendingActivity> 
   a prov:Activity; 
   prov:generated <Y>
   prov:used              <X>
   prov:wasAssociatedWith <B>

In web annotation, this would be something like

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "http://example.org/descriptionAnnotation",
  "type": "Annotation",,
  "body": "http://example.com/Y",
  "target": "http://example.com/X"
}

# or focused on the description itself:

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "http://example.org/descriptionAnnotation",
  "type": ["Annotation", ":Description"],
  "bodyValue": "D2",
  "target": "http://example.com/X"
}

(THB, I don't think Web Annotations fits the use case we have here, because the description itself is not something we publish as a resource)

Conclusion

IMO, the collection does not change; both B and L are describing the same thing and are therefore following the "anyone can say anything about anything" principle. Hence, it makes sense that the collection is only represented by a single resource and B also describes . When both descriptions are merged, you need provenance information of the statements. RDF-star and RDF-reification seem like the most lean/orthogonal ways to do this, but using rdf:value or schema:Role would (for this use case at least) also work.

If for practical reasons, a new resource must be created (eg. the data pod of B needs a LDP container to store the data under ), then a owl:sameAs or skos:exactMatch would work, although you could use PROV as well.

[lem-onade]

Note that the app currently uses @inrupt/solid-client for accessing data. Back when we were discussing the heritage object data model, we found out blank nodes aren't supported by this lib. I would guess it does not support RDF-star, n-ary relationships either.

[mielvds]

@inrupt/solid-client uses https://www.npmjs.com/package/n3, which should parse and write RDF-star with the right settings. It might be supported or be low-effort to implement, so I'll create an issue in any case.

[coret]

I have some questions in regards to the scenario:

• B decides to add its own description D2 of X.
• D2 is now visible in Solid CRS of L

Maybe it's "old thinking" but isn't L the "authority" on the data of X. This makes the action of B - adding it's own description - seem questionable. But if this is the distributed way, then I think we still have to consider if the data-model suits L in the case that they want to alter D1 as was suggested by D2. Will L get a notification about D2 for X from B?

And, will B show only D2 or D2 and D1 with provenance info?

[mielvds]

Maybe it's "old thinking" but isn't L the "authority" on the data of X. This makes the action of B - adding it's own description - seem questionable.

Although I think this happens in practice more often that we would like, I probably should have picked a different example. The issue also exists when there is no conflict:

<X> a schema:Dataset. # triple from L
<X> :onDisplayIn <expo>. #triple from B

Regardless of whether this data shows up in CRS of L or B, you have no way of telling who added what.

But if this is the distributed way, then I think we still have to consider if the data-model suits L in the case that they want to alter D1 as was suggested by D2.

Data model means schema.org or the scenarios described here?

Will L get a notification about D2 for X from B?

Yes (but this is not mandatory)

And, will B show only D2 or D2 and D1 with provenance info?

D2 and D1 are shown side by side

[EnnoMeijers]

I think you made an error in describing the scenario, instead of "D2 is stored in the data pod of L" it should be "D2 is stored in the data pod of B".

Next to that I would suggest to look at the level of objects instead of collections, which are basically containers of objects. I am not sure if I can follow the different solutions you describe above, but looking at the problem on the level of single object published as resource than I do not understand why the web annotation model wouldn't fit here? I would prefer to choose this direction because it is compliant with current standards and implementations and is probably the most safe route to implement.

And regarding the display of data in B, I would think that B only wants to show the edited/annotated version in it is own pod, that being the final state that B likes to present to it users. After receiving the notification of B it is up to L to process the edit or annotation into the original object and in order to make a sound judgement it is needed for L to see both D1 and D2 side by side.

[mielvds]

I think you made an error in describing the scenario, instead of "D2 is stored in the data pod of L" it should be "D2 is stored in the data pod of B".

Good catch! I corrected it.

Next to that I would suggest to look at the level of objects instead of collections, which are basically containers of objects.

Okay, but that doesn't immediatly affects this issue. Even if you annotate an object instead of a container, you need to indentify annotations by source.

I am not sure if I can follow the different solutions you describe above, but looking at the problem on the level of single object published as resource than I do not understand why the web annotation model wouldn't fit here? I would prefer to choose this direction because it is compliant with current standards and implementations and is probably the most safe route to implement.

Maybe I'm confused about the exact use case, but the web annotation recommendation is targeted at connecting two (non-information) resources on the web, eg. a text comment to an image, a sound file to a video, etc. In other words, the source ('body' in web annotation terms) and target are resources, which are identifyable by IRI. If B annotates X with a local rack number in their storage, it's not clear how you would indicate both 5 and rack_number.

And regarding the display of data in B, I would think that B only wants to show the edited/annotated version in it is own pod, that being the final state that B likes to present to it users. After receiving the notification of B it is up to L to process the edit or annotation into the original object and in order to make a sound judgement it is needed for L to see both D1 and D2 side by side.

Yes indeed, so L sees side-byside and B sees a merged view of the latest state.

[mielvds]

We discussed it a bit further and twe can take the following pragmatic approach using Named Graphs. CSS should support this without problems, athough I'm not a 100% sure how the Solid API will react.

In application/trig:

@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

#When retrieving <X> at L
<L/G> {
  <X> schema:description "D1"
}

<L/G>  schema:created   "2022-01-16T01:52:02Z"^^xsd:dateTime;
             schema:author <L>.

#When retrieving <X> at B
<B/G> {
  <X> schema:description "D2"
}

<B/G>  schema:created   "2022-01-20T01:52:02Z"^^xsd:dateTime;
             schema:author <B>.

But if this doesn't work with the solid-client, your best chance is to use option 1 reification:

// Perspective of L
const a = buildThing()
  .addUrl(rdf.subject, "X")
  .addUrl(rdf.predicate, schema.description)
  .addStringNoLocale(rdf.object, "D2")
  .setDatetime(schema.created, "2022-01-20T01:52:02Z")
  .addUrl(schema.author, "D2")
  .build();

[lem-onade]

I've discussed this yesterday with @woutermont and we bumped into a flaw with (I think) all of the above proposals: there is no easy way to indicate one of the properties' value has been removed.

For example, the description D1 is incorrect, so B decides to get rid of this incorrect information in D2. We can't provide a value for D2 as it doesn't exist. Providing an empty string as value might work, but seems off.

A solution could be, at the side of B, to keep track of some kind of change set, instead of only the changed values. This could differentiate between changes and deletions. However, I'm not sure if a model like this exists already and it might take longer to implement.

I'll assume the deletion issue doesn't exist.

Is there a benefit for using named graphs over just saving the additions in a different resource in the pod of B?

webid.L/objects -- containing the full, original object

  <#object-1>
    schema:maintainer <webid.L> ;
    schema:description "D1" ;
    ...

webid.B/objects -- containing only changes to the original

  <webid.L/objects#object-1>
    schema:maintainer <webid.B> ;
    schema:description "D2" .

Can we re-use existing schema:maintainer to indicate who made the updates?

[mielvds]

@lem-onade I think this is more of an UI issue than a data modeling issue. In RDF, there is typically an Open World assumption, so If something is missing, you're not sure it doesn't exist. Typically, you would annotate a deleted fact the same way you would annotate it with its source:

<X> schema:description "D1". # from L

_:1 rdf:type rdf:Statement ;
      rdf:subject <X>; 
      rdf:predicate schema:description; 
      rdf:object "D2";
      ex:deleted true;
      schema:created   "2022-01-16T01:52:02Z"^^xsd:dateTime;
      schema:author <B>.

The solution you propose is basically creating a duplicate resource and describing that one. B is no longer describing the same resource. I wonder whether this is still semantically correct, but fine by me for taking this route. It would work for this particular context, but note that it's more of an engineering solution.

• How are these resources linked and what does this link mean?
• Is<webid.L/objects#object-1> an annotation of <#object-1>?
• If I encounter this data in the Pod of B outside of Solid CRS, how do I know that one is a delta of the other?