Sort and partition by subject IRI

[bergos]

In my use case, I handle a set of subjects with zero knowledge about the structure. The IRIs are used for sorting because there is nothing besides the subjects. I represent it as shown below. The spec currently says that a tree:Relation should have a tree:path but doesn't define what the absence of tree:path means. I see two possible interpretations:

• An undefined logic is used, but tree:value refers to a term in the structure of the member.
• The path is empty, and tree:value refers to the member subject.

A more explicit representation for my use case could be tree:path with an empty list as object: tree:path ()

Both options, the absence of tree:path and tree:path with an empty list as object are OK for me, but I think it should be mentioned in the spec.

<> a tree:Collection;
  tree:member
    <metasequoia-disticha>,
    <metasequoia-foxii>,
    <metasequoia-glyptostroboides>,
    <metasequoia-heeri>,
    <metasequoia-heerii>,
    <metasequoia-honshuenensis>,
    <metasequoia-neopangaea>,
    <metasequoia-occidentalis>,
    <pinus-abies>,
    <pinus-alepensis>;
  tree:view <?limit=10>.

<?limit=10> a tree:Node;
  tree:relation [ a tree:GreaterThanRelation;
    tree:node <?limit=10&offset=10>;
    tree:value <pinus-alepensis>
  ].

[pietercolpaert]

Thanks for not confusing anybody by creating a TREE Collection of actual trees :sweat_smile:

 <>  tree:view <?limit=10>.

<?limit=10> a tree:Node;
  tree:relation [ a tree:GreaterThanRelation;
    tree:node <?limit=10&offset=10>;
    tree:value <pinus-alepensis>
  ].

I’m not sure what this tree:GreaterThanRelation would mean on a named node though? It seems like it orders the URIs alphabetically? I believe adding the actual literal that can be used by the comparator would be useful. Even if it is lacking however, I would propose to even then add a tree:path to the actual literal that could be found elsewhere, such as tree:path rdfs:label if it is indeed ordered alphabetically on name.

but doesn't define what the absence of tree:path means

In the absence of tree:path, there’s a fallback defined in which the comparator needs to be applied on all literals attached to the member that can be compared. See https://w3id.org/tree/specification#fallbacks

[bergos]

Thanks for not confusing anybody by creating a TREE Collection of actual trees sweat_smile

The tree dataset was there before the API spoke TREE :-)

I’m not sure what this tree:GreaterThanRelation would mean on a named node though? It seems like it orders the URIs alphabetically? I believe adding the actual literal that can be used by the comparator would be useful. Even if it is lacking however, I would propose to even then add a tree:path to the actual literal that could be found elsewhere, such as tree:path rdfs:label if it is indeed ordered alphabetically on name.

Generating a label requires understanding the data. I'm looking for something generic where this is not required.

It looks like this is a special case for two individual topics:

Starting point of tree:path

Let's ignore the term types of subjects and objects. tree:path describes how to traverse to the relevant term. That requires having a starting point and an endpoint. At the moment, it's described like this:

indicating the path from the member to the object on which the tree:Relation applies

Can we change object to term? It's already possible to refer to a subject with sh:inversePath. Then that case would be covered. And it would be possible to have an empty path, not traverse at all, and the member is start and endpoint.

Sorting terms

Sorting works already in my code, so how is it done? I use SPARQL, and SPARQL defines a logic for it. Can't we just refer to the ORDER BY section of the SPARQL specification?

In the absence of tree:path, there’s a fallback defined in which the comparator needs to be applied on all literals attached to the member that can be compared. See https://w3id.org/tree/specification#fallbacks

Oh, I missed that. I only read the parts which I thought were relevant to me. I will go through the whole specification before the next call.

Does it makes sense to link from tree:path to the fallback section?

[pietercolpaert]

• [ ] Ok to change object to term
• [ ] Ok to refer to the fallback section

I don’t understand how SPARQL ORDER BY would work or how your initial example would work though. The user story would be a client that wants to find e.g., the 10 smallest trees. If you have a GreaterThanRelation, it it still important to give a tree:path to the property of the tree. E.g., ex:averageSize, and that you have a tree:value indicate greater than what value the average size will be.

In your example right now it’s unclear what greater than would mean: what property of the tree are we talking about?

[pietercolpaert]

In the newly proposed member extraction algorithm in PR #78, it now also becomes possible to have a view where all members need to be dereferenced if you want to get to the properties of a member, as in your example.

In your example however, I’d use tree:qualifiedValue instead though to refer to an entity with a value that must be greater than what you indicate, and then also include a tree:path to indicate the exact property that must be compared: is it the maximum size, is it the circumference of the leaves, etc.

[pietercolpaert]

During the call of 29th of November 2023 we discussed that the intention here is to really sort URIs, and not properties of the entity.

We discussed 2 possible action points from this use case:

1. Refer to the SPARQL ORDER BY spec for evaluating relations with named nodes (related to #76)
2. Checking what should happen with an empty tree:path rdf:List: would it select the current focus node? Add this as a test case