Templates, Generics, and Parametric Polymorphism in Semantic Web Languages [Was Re: Syntactic Options for Probabilistic Semantics]

With respect to syntactic possibilities for templates, generics, and parametric polymorphism in Semantic Web languages, it occurs that all the brackets are already in use...

How, then, might we represent templates and generics? One possibility is to utilize a list-like syntax for arguments and some sort of connector, like:

<http://www.example.org/#Widget>^^(ex:Foo ex:Foo2 ex:Foo3)

ex:Widget^^(ex:Foo ex:Foo2 ex:Foo3)


Here is how it would look with recursive structure:



<http://www.example.org/#Widget>^^(ex:Foo ex:Foo2^^(xsd:integer) ex:Foo3)

ex:Widget^^(ex:Foo ex:Foo2^^(xsd:integer) ex:Foo3)

Do any other syntactic possibilities come to mind?


Best regards,

Adam

________________________________
From: Adam Sobieski <adamsobieski@hotmail.com>
Sent: Monday, December 12, 2022 2:37 PM
To: William Van Woensel <william.vanwoensel@gmail.com>
Cc: Doerthe Arndt <doerthe.arndt@tu-dresden.de>; semantic-web@w3.org <semantic-web@w3.org>
Subject: Re: Syntactic Options for Probabilistic Semantics


William,

All,



Thank you for the useful example. I've been recently thinking about "graph reification" which is showcased in your example: http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R .



N3 Syntactic Sugar

As interesting, here are some more rough-draft syntactic sketches:



@foreach(rdf:Statement ?stmt in example:graph1 insert example:graph2)

{

   ...

}





@foreach(ext:Graph ?g in example:dataset1 insert example:graph2)

{

  ...

}





@foreach(ext:Graph ?g in example:dataset1)

{

  @foreach(rdf:Statement ?stmt in ?g insert example:graph2)

  {

     ...

  }

}





N3, Client-side Preprocessing, Templates and Generics


In addition to client-side PHP [2], I am also thinking about N3 as a potential "semantic preprocessing" technology. With client-side preprocessing [1], runtime arguments – including entire graphs or knowledgebases – can be provided to preprocessors which can then access the graphs or knowledgebases to utilize program logic to vary output contents, e.g., TriG content.

As envisioned, graphs or knowledgebases would be provided to preprocessing environments as implicit arguments alongside possible explicit arguments which could be URIs or data types, e.g., boolean values, strings, or numerical values.

Towards using N3 in a semantic preprocessing capacity, one could define a reserved input graph name, e.g., “urn:reserved:input”, for an input graph or knowledgebase to be provided at runtime. There would, then, be a matter of how one might best express other input parameters (e.g., T, or T1, T2, T3) which would, similarly, be bound to argument values when invoking the preprocessor.

Scenarios considered include, broadly, templates and generics. For a concrete example, “ex:Widget<ex:Dog>” and “ex:Widget<ex:Person>” might result in output content which differs based on facts asserted in the provided graph or knowledgebase about dogs and people, e.g., a dog has four legs and a person two. The preprocessing logic which would produce these generic types would receive an implicit argument, a graph or knowledgebase, and an explicit argument value, in this case a URI, for a template parameter T, e.g., "ex:Dog" or "ex:Person".

As envisioned, output content from semantic preprocessing could be semantic graphs. In the running example, the output content might represent a type or class. Resultant types or classes might have URIs resembling: “http://www.example.org/?T=http%3A%2F%2Fwww.example.org%2F%23Dog#Widget” and “http://www.example.org/?T=http%3A%2F%2Fwww.example.org%2F%23Person#Widget”.

While I’m looking at these preprocessing scenarios towards advancing expressiveness for planning domain definitions, other applications of interest to me include machine lexicons. For instance, “verb:Walk<ex:Dog>” and “verb:Walk<ex:Person>” might have similar but differing semantic content, e.g., definitions differing as dogs have four legs and people have two.




Best regards,

Adam



[1] https://github.com/w3c-cg/planning/discussions/21

[2] https://github.com/seanmorris/php-wasm

________________________________
From: William Van Woensel <william.vanwoensel@gmail.com>
Sent: Monday, December 12, 2022 9:35 AM
To: Adam Sobieski <adamsobieski@hotmail.com>
Cc: Doerthe Arndt <doerthe.arndt@tu-dresden.de>; semantic-web@w3.org <semantic-web@w3.org>
Subject: Re: Syntactic Options for Probabilistic Semantics

Hi Adam

See here for some examples on how you can infer new statements based on the contents of a graph:
http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R

(These are arbitrary examples; if you had something concrete in mind, I can try to write a better example.)

I think the syntactic sugar you propose could be intuitive for this kind of use case (a more imperative style of programming).


W

> On Dec 11, 2022, at 3:37 AM, Adam Sobieski <adamsobieski@hotmail.com> wrote:
>
> Dörthe,
> All,
>
> With respect to syntactic options for probabilistic logic and semantics, I recently created a GitHub discussion thread: https://github.com/w3c-cg/planning/discussions/26#discussioncomment-4369123 . The most recent comment, there, broaches some syntactic options including some discussion that RDF-star is useful for these scenarios.
>
> For instance:
>
> << ex:myPredicate calc:holdsFor ( ex:x ex:y ex:z ) >> calc:probability "0.95"^^xsd:double .
>
> and (see also: https://github.com/w3c/rdf-star/issues/276):
>
> << ex:myPredicate calc:holdsFor ( ex:x ex:y ex:z ) >> calc:probability "0.95"^^xsd:double {| o:accordingTo ex:Alice |} ,
>                                                                      "0.96"^^xsd:double {| o:accordingTo ex:Bob   |} .
>
> Considering these intricate RDF-star examples, above, the @-directive approach, broached earlier, might not have been the best syntactic option for probabilistic logic and semantics...
>
> While the N3 design appears to be migrating from @-directives (https://w3c.github.io/N3/spec/#changes-since-team-submission), brainstorming, here is an idea, expressed using a @-directive syntax (other syntaxes possible), which pertains to iterating over statements in one named graph to process a second graph and to assert content from it.
>
> The following example intends to express, for each statement, ?statement, in a named graph, example:graph1, that we desire to process and to assert the contents of example:graph2.
>
> @foreach(?statement in example:graph1 insert example:graph2)
> {
>     example:graph1
>     {
>         ### this graph is iterated and not added to the deserialized graph or dataset
>         example:x1 example:p1 example:y1 .
>         example:x2 example:p2 example:y2 .
>         example:x3 example:p3 example:y3 .
>     }
>     example:graph2
>     {
>         ### the ?statement iterand variable can be utilized throughout this graph.
>         ### there could be a path-related notation utilized to obtain the iterands' subjects, predicates, objects, and so forth.
>         ### for each iterated statement, this template graph is to be processed and added to the graph or dataset being deserialized.
>     }
> }
>
> What do you think of this abstract idea? If such a feature would be useful, is there a better syntax for it?
>
>
> Best regards,
> Adam
> From: Adam Sobieski <adamsobieski@hotmail.com>
> Sent: Thursday, November 24, 2022 10:46 AM
> To: Doerthe Arndt <doerthe.arndt@tu-dresden.de>
> Cc: semantic-web@w3.org <semantic-web@w3.org>
> Subject: Re: Syntactic Options for Probabilistic Semantics
>  Dörthe,
>  Thank you. I also like the solution you presented which uses a defined and well-known vocabulary.
>  Comparing these two options, with a @-directive-based approach underlying storage approaches, implementations, would seemingly be more flexible. With the solution you shared, the underlying storage approach appears to be more rigidly graph-based.
>
> Clarifying, with respect to runtime memory storage approaches, many implementations provide a "Triple" class and an implementation could provide, for probabilistic semantics, a "ProbabilisticTriple" class with a new property or new method: "getProbability()". In theory, such a virtual method could be added to the "Triple" class and implemented there to always return 1.0 (or <1.0, 0.0, 0.0>). "ProbabilisticTriple", extending "Triple", could override this virtual method, e.g., to return varying data.
>  With respect to backend implementation approaches, in the case of database storage, certain tables could provide an extra column for probability-related data. Were it not for consideration of neutrosophic logics, we could envision such columns to always simply be scalars.
>  With either of the two options, with some new syntax, e.g., @-directive-based, or a well-known vocabulary for probabilistic semantics, software can readily detect when probability-related content appears in data or queries. That is, software could detect when to deserialize to "Graph" and when to deserialize to "ProbabilisticGraph".
>
> These are some initial thoughts about comparing these two options.
>
> Best regards,
> Adam
>
> P.S.: It appears that there is an opportunity to update the Wikipedia article on probabilistic semantics.
>
> From: Doerthe Arndt <doerthe.arndt@tu-dresden.de>
> Sent: Thursday, November 24, 2022 7:53 AM
> To: Adam Sobieski <adamsobieski@hotmail.com>
> Cc: semantic-web@w3.org <semantic-web@w3.org>
> Subject: Re: Syntactic Options for Probabilistic Semantics
>  Dear Adam,
>
> I like your idea to express probabilistic semantics with N3, but I would like to clearly understand why you think that we need the @-based directives for it instead of using the language as it is together with a defined vocabulary. The background here is, that in the N3 group we try to avoid keys and special constructs where possible.  So, why would you need the special construct?
>
>>
>>
>> Brainstorming, we could, in a manner resembling other @-based directives in N3, express:
>>
>> @p(0.95) . { domain:X domain:r domain:Y . }
>
>
> Instead of writing that, you could also simply add some predicate :probability (of course using a shared vocabulary and not just something made up ad-hoc) and state:
>
>
>> { domain:X domain:r domain:Y . } :probability 0.95.
>
> The advantage of doing so is, that you would even be able to reason with your probabilities without any extra effort. If you have the probability of a person having black hair and the probability of a person being male
>
> {:person a :Male} :probability 0.49.
> {:person :hairColor :black } :probability 0.3.
>
> You could use a rule to calculate the probably of encountering a male with black hair just like:
>
> {
> {?s ?p ?o} :probability ?x.
> {?s ?p2 ?o2} :probability ?y.
> {?s ?p ?o} log:notEqualTo {?s ?p2 ?o2}.
> (?x ?y) math:product ?z.
> ({?s ?p ?o} {?s ?p2 ?o2}) log:conjunction ?c
> }=>{
> ?c :probability ?z
> }.
>
> And get that
>
> {:person :hairColor :black. :person a :Male} :probability 0.147 .
>
> You can also directly try the example here: http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T
> I would of course expect, that the rules you would actually need for proper probabilistic semantics are far more complicated, but I also think that the built-ins in N3 would allow you to write some exchangeable rules supporting the theory. So, having these nice implementations at hand, I wonder why you would want to ask for extra syntax? You could stay in the syntax as it is and define a vocabulary (ontology, depending how far you go) for the concept of probability which we would then reuse.
>
>>
>> Also, beyond [0, 1] scalars per fuzzy logic, there are multivalued logics, e.g., neutrosophic logics which describe every logical variable x as being described by a triple: x = (t, f, i), where t is the degree of truth, f is the degree of false, and i is the level of indeterminacy. We could express this in a manner resembling:
>> @p(t: 0.95, f: 0.05, i: 0.0) . { domain:X domain:r domain:Y . }
>
>
> Would
>
> { domain:X domain:r domain:Y . } :probability_t 0.95, :probability_f 0.05, probability_i: 0.0.
>
> also do the job? Why would you want to have the special format?
>
>
>>
>> What do you think of these syntactic options for expressing probabilistic semantics in N3-based languages?
>
>
> Before I form an opinion, I really need to understand, why we would need extra syntax here. I am sure, I am missing something, but so far, it looks to me that the proposal rather complicates the language than bringing extra advantages. Maybe an example could help?
>
> Kind regards,
> Dörthe