Use case: alias for property paths

[recalcitrantsupplant]

I have a few cases in recent projects where clients would like to flatten RDF, for example to generate a CSV, or render a table in HTML without complex nesting or needing to somehow indicate inverse paths visually etc.
I'm already expressing the property paths that are in scope to describe a resource using sh:union.
I would like a way to say there is an alias for the path, something like sh:pathAlias, and I would like the range to be an IRI so I can reference the shape / full property path that the alias is for.
Looking at the spec I believe sh:name can have an IRI in its range, though I don't my use case aligns with the intended use of the property.

sh:union (
    [ sh:path ( sosa:isSampleOf [ sh:inversePath dcterms:hasPart ] schema:identifier ) ]
    ... other property paths

sh:union (
    [ 
        sh:path ( sosa:isSampleOf [ sh:inversePath dcterms:hasPart ] schema:identifier ) ;
        sh:pathAlias <https://parent-identifier>
    ]
        ... other property paths

In my specific use case I'm translating this to SPARQL, so in the construct triples I would use the alias, and in the where clause use the full property paths.

I believe this is possible with rules and the proposal around "calculated" fields may suit too, ideally something more succinct as above would be good - I often have 10+ property paths for a particular "profile" of a resource.

[HolgerKnublauch]

Yeah, we are using sh:values for such use cases.

Introducing sh:pathAlias to sh:PropertyShape would be quite a big change. To clarify are you only referring to node expressions here, e.g. introduce a sh:pathAlias node expression function in addition to sh:path? (I see this issue is not tagged Core yet, but I want to confirm).

[recalcitrantsupplant]

I can't find sh:values, I'm familiar with sh:value/sh:hasValue but I don't think either of those would suit?

This came up briefly in the last meeting. My thinking is now that so long as there's an equivalent way to express this in SHACL i.e. a rule, it would be better for me to just maintain this as an extension in my own implementation. Otherwise I can see there could be a lot of extensions like this that bloat the spec.

If it were added, I would think it would make sense for property paths in general, though in my implementation I've only ever used it in node expressions.

[tpluscode]

I can't find sh:values

It is used in SHACL-AF draft: https://w3c.github.io/shacl/shacl-af/#PropertyValueRule

[HolgerKnublauch]

Yes, for example the SHACL-AF syntax to declare an alias property would be

ex:SomeShape-aliasProp
    a sh:PropertyShape ;
    sh:path ex:aliasProp ;
    sh:values [
        sh:path ( sosa:isSampleOf [ sh:inversePath dcterms:hasPart ] schema:identifier )
    ] .

and then you can basically reuse this via node expression [ sh:path ex:aliasProp ]

[tpluscode]

and then you can basically reuse this via node expression [ sh:path ex:aliasProp ]

By the way, is this something hypothetical or have you been doing this in TopBraid?

[HolgerKnublauch]

In TopBraid for sure. I notice that the SHACL-AF draft doesn't mention it https://w3c.github.io/shacl/shacl-af/#node-expressions-path but it always was my understanding.

[tpluscode]

I only worked with AF for SPARQL generation and never tried to reuse properties by their alias.

What happens when an inferred/generated property exists in the data graph? Are the (pre)asserted and generated values combined?

[HolgerKnublauch]

The 1.2 Core spec states that sh:values AND asserted triples will be combined.