SHACL Rules: Add rule sets to RDF vocabulary

[HolgerKnublauch]

It may be useful to group rules into sets that are supposed to be executed together. SRL relies on that concept.

Suggestion:

ex:Rule1
    a sh:SPARQLRule ;
    sh:ruleSet ex:RuleSet1 .

ex:RuleSet1
    a sh:RuleSet ;
    sh:importsRuleSet ex:RuleSet2 .

ex:RuleSet2
    a sh:RuleSet . 

The naming is chosen to be consistent with SRL which has an IMPORTS keyword and owl:imports.

We point from Rules to RuleSets similar to how property shapes point to property groups. Rules may be in multiple sets.

There is an unnamed default rule set per graph which consists of all rules that do not have a sh:ruleSet triple.

[nicholascar]

Good one @HolgerKnublauch, great to see the set capability

[liviorobaldo]

why don't we simply treat rule sets as classes? So in place of:

ex:Rule1
    a sh:SPARQLRule ;
    sh:ruleSet ex:RuleSet1 .

we have:

ex:Rule1
    a sh:SPARQLRule ;
    a ex:RuleSet1 .

These triples, instead, remain as you proposed:

ex:RuleSet1
    a sh:RuleSet ;
    sh:importsRuleSet ex:RuleSet2 .

ex:RuleSet2
    a sh:RuleSet . 

So, basically sh:RuleSet parallels rdfs:Class.

[HolgerKnublauch]

What do you see as advantages of this? It would make sh:RuleSet a metaclass (rdfs:subClassOf rdfs:Class).

I prefer to have an explicit relationship instead of overloading rdf:type here.

[liviorobaldo]

I prefer to have an explicit relationship instead of overloading rdf:type here.

As for me, I generally prefer to reuse existing symbols rather than introduce new ones. So, if we can reuse rdf:type, why do we need to introduce a new symbol into the vocabulary, i.e., sh:ruleSet... which is even almost identical to sh:RuleSet and could therefore very easily lead to confusion?

What do you see as advantages of this? It would make sh:RuleSet a metaclass (rdfs:subClassOf rdfs:Class).

And what would be the problem/disadvantage of making sh:RuleSet a metaclass (rdfs:subClassOf rdfs:Class)? Aren't classes sets?

In any case, from the point of view of expressiveness, the two alternatives are equivalent; it is ultimately a matter of preference. However, minimizing the number of symbols in the vocabulary, especially when the new symbols are almost identical to existing ones, seems to me to be a valid preference criterion for choosing between the two alternatives.

[HolgerKnublauch]

If we take this argument (minimizing new properties/symbols) further, it would for example also mean that these would also be alternatives:

ex:Holger ex:worksFor ex:TopQuadrant
ex:Holger a ex:TopQuadrant

or

ex:Person-firstName sh:group ex:LabelProperties
ex:Person-firstName a ex:LabelProperties

Furthermore, what would happen if RuleSets can again be in an orthogonal set relationship. You would need multiple levels of rdf:type here.

Introducing identifiers such as property URIs is cheap and a key building block of RDF-based standards. sh:ruleSet follows established best practices.

[liviorobaldo]

If we take this argument (minimizing new properties/symbols) further, it would, for example, also mean that the following would be alternatives:
ex:Holger ex:worksFor ex:TopQuadrant
ex:Holger a ex:TopQuadrant

I don't think this is a valid example. TopQuadrant is not a set; it is an individual (ex:TopQuadrant a ex:Company). Treating a company as the set of people who work for that company does not seem to be a sound ontological modelling choice.

The same applies to sh:group: I don't see the parallel with rdf:type. If I understand it correctly, sh:group is used to group properties, e.g., to indicate that a street name or postal code is part of an address. Thus, it reflects more the standard part-of relationship rather than rdf:type, which denotes set membership.

Furthermore, what would happen if RuleSets can again be in an orthogonal set relationship. You would need multiple levels of rdf:type here.

I don't quite understand this point. Could you give an example?

[afs]

sh:importsRuleSet

sh:includeRuleSet would be better (if this is a same-document reference).

owl:imports and IMPORTS both execute HTTP GETs.

[HolgerKnublauch]

@liviorobaldo A Company can be seen as a set of employees. A family can be seen as a set of family members. Only because something is called XYset doesn't mean that it deserves to be treated very differently from other relationships between members and collections.

Rule Sets are also individuals. They don't really benefit from being declared as classes, e.g. what would owl:equivalentClass mean on rule sets, or what happens if a ruleset is also a NodeShape etc.

I feel we are getting lost on a rather academic tangent here.

[HolgerKnublauch]

@liviorobaldo a less academic but rather practical argument: with a dedicated property, it becomes easier to query the data that you need. So to find out what rule sets a rule belongs to, we just need to query ?rule sh:ruleSet ?ruleSet. With rdf:type, we would also need a FILTER (?ruleSet a/rdfs:subClassOf* sh:RuleSet). Likewise, with a dedicated property we can make the contracts machine-readable, e.g. via SHACL constraints (in SHACL-SHACL) to say that the expected values are sh:class sh:RuleSet. Again, much more messy if we reuse an already existing property, and rdf:type in particular. rdf:type for rules already has the meaning to resolve the rule type, and thus the supported evaluation algorithms.

[afs]

?rule sh:ruleSet ?ruleSet

does not really indicate the direction of the relationship.

How about indicating it is a member by saying in (as in "in set") or memberOf.

?rule sh:inRuleSet ?ruleSet .