Local URIs [was Re: Towards N-ary Predicate Calculus in TriG]

On 12/10/22 13:40, Adam Sobieski wrote:
> 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?

I think the existing syntax for relative URIs would be just fine to use 
for local URIs, such as:

   <obj42> rdfs:label "Object 42" .

I don't think the original purpose of relative URI syntax is really 
needed in RDF.  Instead of expanding them to absolute URIs (as currently 
done for relative URIs), RDF processors could keep them as local URIs. 
And when combining two  RDF datasets alpha and beta that might use the 
same local URIs for different purposes, the relative URIs could easily 
be standardized apart by prepending a source string, such as "alpha/" or 
"beta/".  So the above triple coming from the alpha dataset would become:

   <alpha/obj42> rdfs:label "Object 42" .

and coming from the beta dataset it would become:

   <beta/obj42> rdfs:label "Object 42" .

This would allow the alpha and beta datasets to be safely merged without 
causing URI collisions.  This "standardizing apart" is similar to what 
is currently done with blank nodes, except that it would be 
user-controlled and predictable.  One of the key problems with blank 
nodes is that their labels change unpredictably when RDF is processed.

A few years ago I started writing up the idea of local URIs.  At the 
time, I was thinking of basing them on URNs:
https://goo.gl/N56fUc
I've since concluded that relative URIs (as currently defined) are not 
needed in RDF, and it would be better to just reuse that syntax for 
local URIs, as described above.

Thanks,
David Booth

> 
> 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/ <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 
> <https://github.com/w3c/EasierRDF/issues/68>
> 
> Thanks,
> David Booth
> 
> 
>> 
>> 
>>     @prefix calculus:
>>     <http://www.w3.org/community/planning/calculus/ontology# 
> <http://www.w3.org/community/planning/calculus/ontology#>> .
>>     @prefix example:  <http://example.org/# <http://example.org/#>> .
>>     @prefix owl:      <http://www.w3.org/2002/07/owl# <http://www.w3.org/2002/07/owl#>> .
>>     @prefix rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns# 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>>     @prefix xsd:      <http://www.w3.org/2001/XMLSchema# <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/>
>> <https://www.w3.org/TR/swbp-n-aryRelations/ 
> <https://www.w3.org/TR/swbp-n-aryRelations/>>
>

Received on Saturday, 10 December 2022 22:39:22 UTC