Use-case : (Excel) tables generation from shapes

[tfrancart]

This is a use-case description for potential use of what we are trying to define here.
I am specifying how some data should be presented in tables (Excel tabs) using shapes (much like https://datashapes.org/forms.html#ValueTableViewer).
Each tab structure is described as a NodeShape. Columns of each table are PropertyShapes. Lines are filled in with targets of each node shapes.

I would like to be able to specify how each table should be sorted. Something like ex:myNodeShape sh:property ex:P1, ex:P2, ex:P3 ; xxx:somePropertyToIndicateSorting (ex:P2 ex:P3): the table would be sorted by whatever property is sh:path of P2, then whatever property is sh:path of P3.

[WilliamChelman]

@tfrancart A pretty good use case indeed! But I would maybe add:

1. Just a list of iris like (ex:P2 ex:P3) might not be enough, as we might want to define ascending or descending order for example. So maybe something like this? (ex:P2 [ sh:path ex:P3 ; xxx:sortDirection xxx:Descending ; ]), considering xxx:Ascending as default if not given?
2. I would propose to use this xxx:somePropertyToIndicateSorting only for the default sorting on the table, so that users can manually select sorting if they so choose.
3. Taking the example given for dash:ValueTableViewer, I would add a xxx:sorting on the sh:PropertyShape directly, so each property could define if they are sortable. And if so, defining which sorting logic to use, for example: if we have id properties that look like "2023.01.200" and "2023.01.1000", we might want to explicitly use a "natural" sorting so that "2023.01.1000" will come first, in opposition to a default string sort.

[tfrancart]

Just a list of iris like (ex:P2 ex:P3) might not be enough, as we might want to define ascending or descending order for example. So maybe something like this? (ex:P2 [ sh:path ex:P3 ; xxx:sortDirection xxx:Descending ; ]), considering xxx:Ascending as default if not given?

Ha yes of course, I forgot that ASC/DESC "detail". I would not use sh:path as you propose though, because what we are pointing at here are shapes, not properties. Why not simply a "non-semantic" property like rdf:value: (ex:P2 [ rdf:value ex:P3 ; xxx:sortDirection xxx:Descending ; ])

I would propose to use this xxx:somePropertyToIndicateSorting only for the default sorting on the table, so that users can manually select sorting if they so choose.

Yes

Taking the example given for dash:ValueTableViewer, I would add a xxx:sorting on the sh:PropertyShape directly, so each property could define if they are sortable.

xxx:sortable true/false

And if so, defining which sorting logic to use, for example: if we have id properties that look like "2023.01.200" and "2023.01.1000", we might want to explicitly use a "natural" sorting so that "2023.01.1000" will come first, in opposition to a default string sort.

Probably this could be known from the datatype, and the datatype could indicate the sorting algorithm to use.

[WilliamChelman]

Ha yes of course, I forgot that ASC/DESC "detail". I would not use sh:path as you propose though, because what we are pointing at here are shapes, not properties. Why not simply a "non-semantic" property like rdf:value: (ex:P2 [ rdf:value ex:P3 ; xxx:sortDirection xxx:Descending ; ])

Ha yeah, I didn't notice those ex:PX were property shapes 😅. Indeed makes more sense and rdf:value feels like a good option.

xxx:sortable true/false

👍

Probably this could be known from the datatype, and the datatype could indicate the sorting algorithm to use.

That could work indeed, but I fear this might be limiting 🤔. If we define such relationship in a given shapes graph, it would force a specific sorting algorithm on all properties of a given datatype. And if we are in a case with those ids being "naively" typed as xsd:string, then setting their sorting would generalise that to all xsd:string values, which might not be a desired behaviour.

And another point adjacent to that: what about sh:or scenarios? For example on skos:notation we could see multiple datatypes coexisting in the same model, so how could we set a consistant sorting algorithm then? 🤔

[tfrancart]

That could work indeed, but I fear this might be limiting 🤔. If we define such relationship in a given shapes graph, it would force a specific sorting algorithm on all properties of a given datatype. And if we are in a case with those ids being "naively" typed as xsd:string, then setting their sorting would generalise that to all xsd:string values, which might not be a desired behaviour.
And another point adjacent to that: what about sh:or scenarios? For example on skos:notation we could see multiple datatypes coexisting in the same model, so how could we set a consistant sorting algorithm then? 🤔

Yes, for these reasons the indication of a sorting algorithm could be attached to a property shape, but if none is found here, it could be looked up on the datatype indicated with sh:datatype, if any.

[bergos]

What about adding it to the property shape? The order of the columns is already there. It would be the first place I would look for a sort property. Having a sortOrder property would match the existing order property concept. Something like this:

ex:sort [
  ex:sortOrder 1;
  ex:sortDirection ex:Asc
]

[tfrancart]

What about adding it to the property shape? The order of the columns is already there. It would be the first place I would look for a sort property.

I think you are actually right and this makes perfect sense. Just as the sh:order property is on a property shape, a sort order should be on property shapes. I was just worried that it makes property shapes not reusable outside of the context of the NodeShape they are attached to, but I guess we need to be consistent with what has been done with sh:order.

[tpluscode]

I would totally consider the draft of sh:orderBy expression from SHACL Advanced Features draft: https://w3c.github.io/shacl/shacl-af/#orderBy

[bergos]

I would totally consider the draft of sh:orderBy expression from SHACL Advanced Features draft: https://w3c.github.io/shacl/shacl-af/#orderBy

I thought I had seen something like this before. How could I have missed it?

[tpluscode]

How could I have missed it?

The draft is notoriously hard to find :D

[bergos]

Can we agree on using orderBy, as it's defined in SHACL Advanced Features? Leave a 👍 if you agree.

[tfrancart]

I don't agree because i am not sure the semantic is the same. The link you provide points to an order by expression which consists of sh:orderBy + sh:nodes + sh:desc. I don't know what sh:nodes means; what is needed in the use-case is only sh:orderBy + sh:desc, not sh:nodes. And from I read one cannot use sh:desc in combination with sh:orderBy directly, using an order by expression is required.

Also, as an order by expression is supposed to have exactly one value for sh:orderBy, how do you sort by more than one column ?

So my proposal would be to attach it directly to property shapes, as you first proposed; we could reuse the same identifiers

ex:myNodeShape sh:property ex:P1, ex:P2, ex:P3 .
ex:P1 sh:path ex:prop1; xx:sortOrder 1; sh;desc true ; .
ex:P2 sh:path ex:prop2; xx:sortOrder 2; .

[tpluscode]

what is needed in the use-case is only sh:orderBy + sh:desc, not sh:nodes

By taking advantage od SHACL-AF we also avoid creating a new set of terms for similar purpose.

how do you sort by more than one column ?

That is precisely what sh:nodes is for. It is used by most expressions to chain them. The sequence of ordering is a chain of expressions nested with sh:nodes

[
  sh:path ex:P1 ;
  sh:orderBy [
    sh:path schema:name ;
    sh:node [
      sh:path schema:age ;
      sh:desc true
    ] ;
  ] ;
] .

Going inside out, the above would translate to SPARQL ORDER BY DESC(schema:age) schema:name

I don't agree because i am not sure the semantic is the same.

Coming back to this, having compared our snippets. Are you talking about ordering columns or rows? For the former sh:order should suffice. I proposed sh:orderBy to actually sort the table's data

[tpluscode]

Just as the sh:order property is on a property shape, a sort order should be on property shapes. I was just worried that it makes property shapes not reusable outside of the context of the NodeShape they are attached to, but I guess we need to be consistent with what has been done with sh:order.

Overall I think that shapes are not always fully reusable. If you have a shape to generate an "excel" table, likely you would not use it directly in other context. sh:order would be a safe choice

If not, then maybe we could advise using a generic term such as dtype:orderIndex

[tfrancart]

Coming back to this, having compared our snippets. Are you talking about ordering columns or rows? For the former sh:order should suffice. I proposed sh:orderBy to actually sort the table's data

rows. I do use sh:order to order columns.

Just as the sh:order property is on a property shape, a sort order should be on property shapes. I was just worried that it makes property shapes not reusable outside of the context of the NodeShape they are attached to, but I guess we need to be consistent with what has been done with sh:order.

Overall I think that shapes are not always fully reusable. If you have a shape to generate an "excel" table, likely you would not use it directly in other context. sh:order would be a safe choice

Exactly. sh:order would be a safe choice to order columns between them. And for the same reason, a property like xx:sortOrder + xx:desc would be asafe choice to sort the rows according to some property shapes.