Question : how to express the sequence order of Records inside a RecordSet ? (to order items in a tree)

[tfrancart]

Sorry if this question sounds stupid or if it was already answered before. What is the expected modelling pattern to indicate the order in which Records are rico:isDirectlyIncludedIn a RecordSet ? The very simple use-case being : I need to display a hierarchical tree of a RecordSet, how am I suppose to order the entries in the tree ? should rico:directlyFollowsInSequence be used ? I could rely on the rico:identifier but there is no garantee that it always corresponds to the sequence of the RecordSet

Some have come to use https://smiy.sourceforge.net/olo/spec/orderedlistontology.html#index to add a sequence number to Records.

[andreasnef]

Hi @tfrancart

Sorting/ordered sets is a challenge in graphs to do efficiently. In the end, rico:followsOrFollowed is what we decided to use. The advantage is that inserting an item into the sequence is easy.

We also considered:

• Just having a Literal with the index number. But inserting would require changing all resources that follow.
• Using the ORE Proxy concept which is suggested by PCDM, for example. However, introducing Proxy resources seemed too heavy for a simple sequence.

I didn't know about the Ordered List Ontology that you mention, but it seems to be similar to the ORE Proxy solution. Apart fro that, it also seems not really maintained?

[tfrancart]

Sorting/ordered sets is a challenge in graphs to do efficiently.

That's why I am asking :-)

In the end, rico:followsOrFollowed is what we decided to use. We also considered:

May I ask who is "we" ? are you referring to the RiC-CM / RiC-O team, and should I take this answer as the RiC-O recommended way to order Records within RecordSet ? or are you referring to your specific RiC-O implementation ?

Just having a Literal with the index number. But inserting would require changing all resources that follow.

But this is a cost that you pay at insertion time. While the "linked-list-like" rico:followsOrFollowed solution is a cost to pay at query/processing time (and the SPARQL query to order the children of a RecordSet using their rico:followsOrFollowed property, while not impossible to write, is relatively tricky). It thus puts the burden on the data consumer, instead of the data producer.

My point is : simple things should be simple, and I imagine that everyone that will use RiC-O beyond the description of a few records will stumble upon this requirement. So, why not provide a literal property with the index number, in addition to, and formally linked to (with an equivalent query) rico:followsOrFollowed ?

(...) However, introducing Proxy resources seemed too heavy for a simple sequence.

Yes

I didn't know about the Ordered List Ontology that you mention, but it seems to be similar to the ORE Proxy solution. Apart fro that, it also seems not really maintained?

I can't tell, but I agree it seems old. Which is another argument to introduce a literal property with the index number in RiC-O : people implementing RiC-O will do this anyway, let's avoid ressurecting zombies ontologies and provide the adequate property directly in RiC-O.

[andreasnef]

"We" is docuteam, and I am talking about our own usage of RiC-O. While several of us are active in RiC-O development, I am not speaking as a member of EGAD.

Of course, all your inputs are valid, and I also think that there is not generic best solution, but depends on the context and what type of queries/updates that are expected. For another type of ordered list (repeated metadata elements), we are also using the position propery of schema.org property. Maybe this helps?

[tfrancart]

Thanks for all your answers !

[florenceclavaud]

My two cents, as a member of EGAD and lead of RiC-O development team:

• as @tfrancart said, I would recommend using rico:directlyFollowsInSequence for ordering Record Resources in a Record Set. It is a new property, added to RiC-O 1.0 a few months ago. It is a subproperty of rico:followsOrFollowed, but a more precise one, which addresses this important need well. The scope note of rico:precedesOrPreceded, the inverse property of followsOrFollowed, says:

The relation does not specify by itself what criteria are used for ordering the sequence. There may actually be zero to many intermediate Entities, ignored or unkown, in the sequence between the two connected Things. Can be used, for example, for specifying that some Record 'precedes' (has next) some Record within a Record Set.

So, rico:folllowsOrFollowed can also be used, but is far less precise; it can also represent a past relation. Finally, rico:directlyFollowsInSequence is a subproperty of the transitive rico:followsInSequenceTransitive, which can thus be inferred automatically and help link (if needed) two record resources that are in the same sequence without being direct successors. Just like rico:directlyIncludes and rico:includesTransitive as concerns hierarchies of RecordResources. BTW @tfrancart, we forgot to represent sequences in RiC-O Converter (I am the first person to be blamed), and so I think we should do it in the v3 ;-).

• RiC-O has from the 0.1 version also included a rico:Proxy class, and two properties, rico:proxyIn andrico:proxyFor. The whole is close to (and inspired by) the OAI-ORE Proxy entity and properties, that are used in the Europeana Data Model (see EDM definition, https://pro.europeana.eu/files/Europeana_Professional/Share_your_data/Technical_requirements/EDM_Documentation//EDM_Definition_v5.2.8_102017.pdf ; and EDM Primer : https://pro.europeana.eu/files/Europeana_Professional/Share_your_data/Technical_requirements/EDM_Documentation/EDM_Primer_130714.pdf). This was added to RiC-O, among other possible needs, for handling in RDF multiple sequencings of records or records sets in the contexts of multiple Record sets. A Record Resource has only one Proxy in the context of one specific Record Set. And it may have many Proxies simultaneously or through time. At the Archives nationales de France, we used this pattern for the PIAAF prototype (qualitative proof of concept; see https://piaaf.demo.logilab.fr/editorial/contexte-technique#traiter-les-sequences-documentaires, and, as an example, https://piaaf.demo.logilab.fr/external/http%3A%2F%2Fpiaaf.demo.logilab.fr%2Fresource%2FFRBNF_proxy_cc96559z-ca59868324934779-d5e30409). We wanted to test it. We have not used this Proxy pattern since this proof of concept. It is true that this is complicated, but this may prove to be useful in some situations, in the future, even here in the AnF.

• IMHO adding a datatype property, e.g. “rankInArrangementSequence” or a more generic “indexNumber”, with domain RecordResource, to RiC-O, is an interesting idea and could be useful, at least, again, when you have to describe record resources whose sequences are stable, which is the main case. Anyway, we must work on refining the model about Record Resources, and about the relations between them. So adding this could be a part of this work. I cannot see exactly for now how you would formally link this new property with rico:directlyFollowsInSequence, so I would be glad to know what you have in mind, Thomas. We could also add a datatype property to tell how many record resources belong to the sequence.

[tfrancart]

I cannot see exactly for now how you would formally link this new property with rico:directlyFollowsInSequence, so I would be glad to know what you have in mind, Thomas.

I am thinking about this (untested) query:

# Asserts that the rico:indexNumber of a record resource is equivalent to the number of preceding siblings
# linked to this resource through the property path rico:directlyFollowsInSequence+
CONSTRUCT {
  ?x rico:indexNumber ?indexNumber .
} WHERE {
  {
  # select the number of preceding siblings and add one to get a 1-based index number
  SELECT ?x ((COUNT(?precedingSibling)+1) AS ?indexNumber)
  WHERE {
    ?recordset a rico:RecordSet .
    ?x rico:isDirectlyIncludedIn ?recordset .
    # fetches all preceding siblings of ?x through the rico:directlyFollowsInSequence predicate, followed recursively
    ?x rico:directlyFollowsInSequence+ ?precedingSibling .
  }
  # count for each ?x
  GROUP BY ?x
  }
}

You can't assert this in OWL, of course. A SHACL rule would be a possibility

[florenceclavaud]

Yes you are right! this would work perfectly. I was thinking of OWL only, so I could not see a way. Thank you!