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.

[tpluscode]

Only comes back to the question you asked. How do you define precedence?

I realise my snippet was slightly misleading. You would order the entire table, not a property

[
  a sh:NodeShape ;
  sh:orderBy [
    sh:path schema:name ;
    sh:nodes [
      sh:path schema:age ;
      sh:desc true
    ] ;
  ] ;
  sh:property [
    sh:path schema:name ; sh:order 1 ;
  ] ;
  sh:property [
    sh:path schema:age ; sh:order 2 ;
  ] ;
] .

See, the ordering expressions and properties are separated. It makes no sense in this context but in other scenarios you may choose to order by properties which are not actually displayed (not in sh:property)

[tfrancart]

See, the ordering expressions and properties are separated. It makes no sense in this context but in other scenarios you may choose to order by properties which are not actually displayed (not in sh:property)

Well, I could just sh:deactivated them.
Be careful, in you example, I think it should be sh:nodes and not sh:node.
Thanks for the detailled example. I need to think about it. My first impression is that it looks fairly complicated.

[tpluscode]

Be careful, in you example, I think it should be sh:nodes and not sh:node.

Yes, fixed

My first impression is that it looks fairly complicated.

Agree. The complete draft of SHACL-AF is indeed quite complex