Re: Towards N-ary Predicate Calculus in TriG

David,


With respect to n-ary predicate calculus, I opened a GitHub discussion thread here: https://github.com/w3c-cg/planning/discussions/26 .
Also, thinking about “local” URIs/IRIs, which “are like relative URIs/IRIs but are relative to a dataset rather than a document base, and are not turned into absolute URIs/IRIs during processing. These could be used instead of explicit blank nodes when one does not wish to allocate a permanent URI/IRI...”, if new syntax is required for local URIs/IRIs, e.g., for Turtle and TriG serializations, what might it resemble?
What about:

  1.  “*:node”,
  2.  “@:node”
  3.  “@local:node"
  4.  “@dataset:node” and “@graph:node” could be of use for distinguishing whether a local URI/IRI is local to a dataset or graph.
  5.  Namespace prefixes, e.g., “this:node”, "local:node", "dataset:node", or "graph:node", could be indicated to be special by uses of reserved URNs for those namespaces mapped with the prefixes.

Some syntactic convention, including an ad hoc one for discussion purposes, would enable producing and discussing examples showing the usefulness of local URIs/IRIs.





Best regards,

Adam

________________________________
From: Adam Sobieski <adamsobieski@hotmail.com>
Sent: Friday, December 9, 2022 4:10 PM
To: David Booth <david@dbooth.org>
Cc: semantic-web@w3.org <semantic-web@w3.org>
Subject: Re: Towards N-ary Predicate Calculus in TriG


David,



Thank you. First-class n-ary predicates and proper arrays would be useful.

I’m presently exploring how SHACL and DASH, e.g., "dash:ListShape", work with lists, towards being able to efficiently validate data containing n-ary expressions using their predicates' definitions.  Is a predicate defined correctly? Does an expression’s argument list have the correct number of elements, as described by the expression's predicate's arity? Are an expression's arguments of the correct types, as described by the expression's predicate's definition?

I'm also looking at reifying n-ary expressions, where "calculus:Expression" could be a subclass of "rdf:Statement" with constraints that a reified expression's "rdf:subject" value would be of type "calculus:Predicate", its "rdf:predicate" could be omitted as it would be "calculus:holdsFor", and its "rdf:object" value would be list shaped.

Possibilities for n-ary predicate calculus expressions include considering predicates to be as functions (see also: the Function Ontology) which receive a number of typed input arguments and return expressions, e.g., "calculus:Expression".

I'm also looking at combining typed arguments with nestable expressions, e.g., "p1(p2(x, y, z), w)", perhaps using "calculus:Expression".





Best regards,

Adam

________________________________
From: David Booth <david@dbooth.org>
Sent: Friday, December 9, 2022 7:50 AM
To: semantic-web@w3.org <semantic-web@w3.org>
Subject: Re: Towards N-ary Predicate Calculus in TriG

On 12/9/22 04:10, Adam Sobieski wrote:
> Hello. What do you think of this rough-draft sketch with respect to a
> mapping from n-ary predicate calculus to TriG?

It looks reasonable to me, at least on casual inspection.  But I'm
convinced that we need a new RDF syntax that *natively* supports n-ary
predicates . . . and has several other features, including:

  - proper arrays (which are semantically very similar to n-ary
predicates if you think of the index as the predicate)

  - "local" URIs/IRIs, which are like relative URIs/IRIs but are
relative to a dataset rather than a document base, and are not turned
into absolute URIs/IRIs during processing.  These could be used instead
of explicit blank nodes when one does not wish to allocate a permanent
URI/IRI.

  - no explicit blank nodes

  - easy URI/IRI importing or renaming, so that a vocabulary can use its
own preferred names for things, but they are still mapped to global
names.   For example, my:name and my:title might map to foaf:name and
dc:title.

  - built-in rules language, as in N3.  I'm grateful that the N3
Community Group is continuing to refine N3:
https://www.w3.org/community/n3-dev/

Sean Palmer also had some very interesting high-level ideas that I have
not yet been able to mentally coalesce into a clear operative vision,
but certainly deserve thought:
https://github.com/w3c/EasierRDF/issues/68

Thanks,
David Booth


>
>
>     @prefix calculus:
>     <http://www.w3.org/community/planning/calculus/ontology#> .
>     @prefix example:  <http://example.org/#> .
>     @prefix owl:      <http://www.w3.org/2002/07/owl#> .
>     @prefix rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>     @prefix xsd:      <http://www.w3.org/2001/XMLSchema#> .
>
>     example:x  rdf:type    calculus:Variable ;
>              calculus:type  owl:Thing .
>
>     example:y  rdf:type    calculus:Variable ;
>              calculus:type  owl:Thing .
>
>     example:z  rdf:type    calculus:Variable ;
>              calculus:type  owl:Thing .
>
>     example:p1  rdf:type      calculus:Predicate ;
>              calculus:accepts  ( owl:Thing owl:Thing owl:Thing ) ;
>              calculus:arity    "3"^^xsd:int .
>
>     example:p2  rdf:type      calculus:Predicate ;
>              calculus:accepts  ( owl:Thing owl:Thing owl:Thing ) ;
>              calculus:arity    "3"^^xsd:int .
>
>     example:g1  rdf:type  calculus:ConjunctiveExpressionSet .
>
>     example:g2  rdf:type  calculus:ConjunctiveExpressionSet .
>
>     example:g3  rdf:type  calculus:ConjunctiveExpressionSet .
>
>     example:g1 {
>          example:p1  calculus:holdsFor  ( example:x example:y example:z ) .
>     }
>
>     example:g2 {
>          example:p2  calculus:holdsFor  ( example:x example:y example:z ) .
>     }
>
>     example:g3 {
>          example:g1  calculus:implies  example:g2 .
>          // or calculus:implies  calculus:holdsFor  ( example:g1
>     example:g2 ) . ?
>     }
>
>
>
>
> Best regards,
> Adam Sobieski
>
> [1] https://www.w3.org/TR/swbp-n-aryRelations/
> <https://www.w3.org/TR/swbp-n-aryRelations/>