Re: Templates, Generics, and Parametric Polymorphism in Semantic Web Languages

Hi Adam,

On 12/15/22 09:05, Adam Sobieski wrote:
> Ok, looking at that example with lines numbered:
> 
>   1. @prefix list:  <http://www.w3.org/2000/10/swap/list# 
> <http://www.w3.org/2000/10/swap/list#>> .
>   2. @prefix log:   <http://www.w3.org/2000/10/swap/log# 
> <http://www.w3.org/2000/10/swap/log#>> .
>   3. @prefix ex:    <http://example.org/# <http://example.org/#>> .
>   4. @prefix graph: <http://www.w3.org/2000/10/swap/graph# 
> <http://www.w3.org/2000/10/swap/graph#>> .
>   5. @prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns# 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>   6.
>   7. ex:ng??(?x ?y) :graph
>   8. {
>   9.     ?x rdf:type foaf:Person .
> 10.     ?y rdf:type foaf:Person .
> 11.     ?x foaf:knows ?y .
> 12.     ?y foaf:knows ?x .
> 13. } .
> 14.
> 15. {
> 16.     ex:ng??(ex:Alice ex:Bob) :graph ?graph .
> 17.     ?graph graph:member ?stmt .
> 18.     ?stmt log:equalTo { ?s ?p ?o } .
> 19. }
> 20. =>
> 21. {
> 22.     ?s ?p ?o .
> 23. } .
> 
> Lines 7 - 13 are the template. Line 7 and line 16 include a new syntax 
> proposal: "URI??(... list ...)" which, at least on line 16, maps with a URI. >
> The "URI :graph { ... }" structure on lines 7 - 13 is borrowed from 
> William's N3 example: http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R> .

Oh!  Thank you, that is VERY important context.  Now I know that the 
target syntax is N3.  And also I know that ":graph" on lines 7 and 16 
was not a typo.  AFAICT, in William's example he either forgot to 
declare the ":" prefix in Turtle/SPARQL, or that N3 Editor has an 
implied declaration for the empty prefix:

   @prefix : <http://n3-editor.org/> .

An empty prefix is permitted in at least Turtle and SPARQL, so I assume 
it is also allowed in N3.

> On line 16 is the template invocation. The part "ex:ng??(ex:Alice 
> ex:Bob)" is the template invocation and also happens to map to a URI: 
> http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Alice&T[]=http%3A%2F%2Fexample.org%2F%23Bob#ng <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Alice&T[]=http%3A%2F%2Fexample.org%2F%23Bob#ng> . In this proposal, template invocations _are_ named graph URIs.

Interesting.  I don't yet see how I should know to turn "ex:ng??(?x ?y)" 
into that long URI.  But maybe that will become clear if I understand 
the components of that URI, which (if I percent-decode it) seems to 
break down into these parts, which I've arbitrarily line numbered:

101. http://example.org/

102. ?
103. T[]=http://example.org/#Alice

104. &
105. T[]=http://example.org/#Bob

106. #ng

Confirming my understanding . . .

Line 101 is derived from "ex:" on line 16, after removing the "#" from 
its prefix expansion.

On lines 103 and 105, the URIs for Alice and Bob come from the actual 
parameters on line 16.

On lines 103 and 105 IDK exactly what "T[]" is about, or whether it 
might be different in other examples.  Would it always be "T[]" for 
every template?

Also on lines 103 and 105, are the square brackets intended to be part 
of a meta syntax, or were they supposed to be percent encoded?  By my 
reading of RFC3986, square brackets are not permitted in a query string:
https://www.rfc-editor.org/rfc/rfc3986#page-49


> With respect to the template invocation, the ex:Alice URI is intended to 
> bind to the template parameter ?x and the ex:Bob URI is intended to bind 
> to the template parameter ?y .

Got it.

> Lines 15 - 23 show some example N3 for invoking the template and using 
> the resultant named graph in N3. Lines 15 - 23 are loosely borrowed from 
> William's N3 example: http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R> .
> 
> I hope that I've clarified what I'm hoping to express with the N3-based 
> example which includes some new, proposed syntax: "URI??(... list ...)" 
> (see also: 
> https://github.com/w3c-cg/planning/discussions/27#discussion-4656864 
> <https://github.com/w3c-cg/planning/discussions/27#discussion-4656864>). 
> The "URI??(... list ...)" syntax is intended to remind of the query 
> string portion of URIs.

Yes, that was very helpful.  But there still seems to be one glaring 
omission: where do you show the final result of template expansion?  As 
a reader trying to understand your template syntax, it is almost 
essential that I see both the before and after.  What would be the N3 
result of applying template expansion to lines 15-23?

Incidentally, I hope that my questions don't seem like objections.  I am 
very glad that you're experimenting and proposing new ideas; I'm just 
having difficulty following them.

Thanks,
David Booth

> 
> Also, some exciting news! Last night, while exploring the "@requires" 
> proposal syntax for semantic templates, I formulated a related 
> "@if/@then/@else" proposal syntax.
> 
> @prefix  list:<http://www.w3.org/2000/10/swap/list#>  .
> @prefix  log:<http://www.w3.org/2000/10/swap/log#>  .
> @prefix  ex:<http://example.org/#>  .
> @prefix  graph:<http://www.w3.org/2000/10/swap/graph#>  .
> @prefix  rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>  .
> @prefix  owl:<http://www.w3.org/2002/07/owl#>  .
> 
> ex:ng??(?kb  ?x  ?y) :graph
> {
>      @requires?kb  holds
>      {
>          ?x  rdf:type foaf:Person .
>          ?y  rdf:type foaf:Person .
>          ?x  owl:differentFrom?y  .
>      } .
>      ?x  foaf:knows?y  .
>      ?y  foaf:knows?x  .
> } .
> 
> @prefix  list:<http://www.w3.org/2000/10/swap/list#>  .
> @prefix  log:<http://www.w3.org/2000/10/swap/log#>  .
> @prefix  ex:<http://example.org/#>  .
> @prefix  graph:<http://www.w3.org/2000/10/swap/graph#>  .
> @prefix  rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>  .
> @prefix  owl:<http://www.w3.org/2002/07/owl#>  .
> 
> ex:ng??(?kb  ?x  ?y) :graph
> {
>      @if?kb  holds
>      {
>          ?x  rdf:type foaf:Person .
>          ?y  rdf:type foaf:Person .
>          ?x  owl:differentFrom?y  .
>      }
>      @then
>      {
>          ?x  foaf:knows?y  .
>          ?y  foaf:knows?x  .
>      }
>      @else { }
> } .
> 
> 
> So, I think we have an "if/then/else" construct conceptually working 
> with semantic templates, it yields one of two graphs. Also, the 
> "requires" construct can, conceptually, map with an "if/then/else" 
> construct where the else graph is the empty graph. So, the two examples, 
> above, can be described as expressing the same thing. More discussion 
> and details are available here: 
> https://github.com/w3c-cg/planning/discussions/27#discussioncomment-4406511 <https://github.com/w3c-cg/planning/discussions/27#discussioncomment-4406511> .
> 
> 
> Best regards,
> Adam
> 
> ------------------------------------------------------------------------
> *From:* David Booth <david@dbooth.org>
> *Sent:* Thursday, December 15, 2022 7:43 AM
> *To:* semantic-web <semantic-web@w3.org>
> *Subject:* Re: Templates, Generics, and Parametric Polymorphism in 
> Semantic Web Languages
> On 12/14/22 20:41, Adam Sobieski wrote:
>> When reading a traditional function (e.g., C/C++/C#/Java/JavaScript), 
>> the statements in “{}” brackets are to be interpreted as occurring in a 
>> sequence. When reading a graph, the contents of “{}” brackets are to be 
>> interpreted as a set. Accordingly, the concept of a function which 
>> returns a graph faces an uphill battle in terms of syntactical clarity 
>> when using “{}” brackets. I will think about clearer examples.
> 
> It's not so much the brackets that are confusing me.  I'm still stuck on
> the very basics of parsing your syntax to understand which parts are
> intended to be the template, the template's formal parameters, the
> template's actual parameters, template invocation notation, etc.
> 
> Here is how I think I'm understanding your example so far.  For clarity,
> I've numbered the lines of your example as follows:
> 
>    1. @prefix list:  <http://www.w3.org/2000/10/swap/list# 
> <http://www.w3.org/2000/10/swap/list#>> .
>    2. @prefix log:   <http://www.w3.org/2000/10/swap/log# 
> <http://www.w3.org/2000/10/swap/log#>> .
>    3. @prefix ex:    <http://example.org/# <http://example.org/#>> .
>    4. @prefix graph: <http://www.w3.org/2000/10/swap/graph# 
> <http://www.w3.org/2000/10/swap/graph#>> .
>    5. @prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns# 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>    6.
>    7. ex:ng??(?x ?y) :graph
>    8. {
>    9.     ?x rdf:type foaf:Person .
> 10.     ?y rdf:type foaf:Person .
> 11.     ?x foaf:knows ?y .
> 12.     ?y foaf:knows ?x .
> 13. } .
> 14.
> 15. {
> 16.     ex:ng??(ex:Alice ex:Bob) :graph ?graph .
> 17.     ?graph graph:member ?stmt .
> 18.     ?stmt log:equalTo { ?s ?p ?o } .
> 19. }
> 20. =>
> 21. {
> 22.     ?s ?p ?o .
> 23. } .
> 
> Lines 1-5 look like standard Turtle prefix declarations, so I think I
> can ignore them for the moment.
> 
> Lines 9-12 (though maybe it's supposed to be lines 8-13?) look like the
> template body, making use of template variables ?x and ?y.  IDK if the
> template is intended to include the braces on lines 8 and 13, but I'll
> come back to that.
> 
> Line 7 is confusing.  It looks like ?x and ?y are intended to declare
> the names of the template's formal parameters.  But I don't know what to
> make of either "ex:ng??" or ":graph" on that line.   I am guessing that
> ":graph" is a typo and was supposed to be "graph:", but even with that
> assumption, I still don't know its purpose on line 7.
> 
> One problem I'm having is that I don't know what is your target syntax.
> I.e., what syntax are you trying to generate as a result of template
> expansion?   If it is Turtle, then I would assume that the curly braces
> are a part of your template language notation.  But if it is N3 (for
> example) then the curly braces are probably intended to be included in
> the generated result.  If that's the case then maybe I should interpret
> all of lines 7-13 to be the template body.  If so, then perhaps ":graph"
> on line 7 is intended to be used as a predicate of a triple in the
> generated result, and lines 8-13 are intended to be the object of that
> triple, as a graph, since N3 uses curly braces to make statements about
> graphs (or "formulae").
> https://www.w3.org/TeamSubmission/n3/#Quoting 
> <https://www.w3.org/TeamSubmission/n3/#Quoting>
> If that's the intended interpretation then it looks like "ex:ng??(?x
> ?y)" is where the subject of that triple would normally appear, so I'm
> guessing that it will be replaced with something else during template
> expansion.  But IDK what "ex:ng??" signifies.  Is it intended to be an
> additional formal parameter to the template, that will be replaced by an
> actual parameter during template expansion?   Or is it the name of the
> template?  Or is it part of the template body (which should appear in
> the generated result)?   Or is it some combination thereof?
> 
> Returning now to lines 15-23, IDK how to interpret them.  One line 16,
> the "ex:ng??(ex:Alice ex:Bob)" looks like the same pattern as
> "ex:ng??(?x ?y)" on line 7, so I am guessing that it is intended to
> express template invocation, which would suggest that "ex:ng??" is maybe
> intended to be the name of the template to be expanded.  But I don't
> know what to make of the rest of line 16 (":graph ?graph ."), nor do I
> know the purpose of lines 15 or 17-23.
> 
> Line 20 uses the "=>" symbol, but IDK if it is part of the meta notation
> that you are using to describe your suggested syntax, or it is an
> intended part of the generated result.   Are lines 15-23 intended to
> expand to an N3 rule, perhaps?
> 
> Again, I'm stuck on the basics here, trying to understand exactly which
> parts of lines 1-23 are intended to be: meta notation that you are using
> to describe your example; template formal parameters; template body;
> template name (if used); template actual parameters; the generated
> result of template expansion using those actual parameters; template
> invocation syntax (if shown); syntax for binding the template formal
> parameters and template body to the template name (if shown), and any
> special template syntax that is used within the template body but is not
> intended to appear literally in the generated result.  If you could
> spell out exactly which parts of lines 1-23 constitute which of those,
> it would help me understand.  Currently, I'm lost.
> 
> Thanks,
> David Booth
> 
>> Here are some sketches of templates, macros, and functions which utilize 
>> the “{}” brackets to produce sets of nested contents.
>> 
>> @prefix list:<http://www.w3.org/2000/10/swap/list# 
> <http://www.w3.org/2000/10/swap/list#>> .
>> @prefix log:<http://www.w3.org/2000/10/swap/log# <http://www.w3.org/2000/10/swap/log#>> .
>> @prefix ex:<http://example.org/# <http://example.org/#>> .
>> @prefix graph: <http://www.w3.org/2000/10/swap/graph# 
> <http://www.w3.org/2000/10/swap/graph#>> .
>> @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns# 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>> 
>> ex:ng??(?x ?y) :graph
>> 
>> {
>> 
>> ?x rdf:type foaf:Person .
>> 
>> ?y rdf:type foaf:Person .
>> 
>> ?x foaf:knows ?y .
>> 
>> ?y foaf:knows ?x .
>> 
>> } .
>> 
>> {
>> 
>> ex:ng??(ex:Alice ex:Bob) :graph ?graph .
>> 
>> ?graph graph:member ?stmt .
>> 
>> ?stmt log:equalTo { ?s ?p ?o } .
>> 
>> }
>> 
>> =>
>> 
>> {
>> 
>> ?s ?p ?o .
>> 
>> } .
>> 
>> The intended semantics of that “ex:ng??(?x ?y)” syntax is that, for each 
>> valid argument for ?x and ?y, a named graph is provided with a 
>> string-based pattern for its URI. That is, wherever the URI-pattern is 
>> utilized, a named graph is provided with contents as described, in the 
>> above case, four statements.
>> 
>> When I look at that sketch, I want to extend it to include guards for 
>> the input parameters, as if it were a function. I want to express that 
>> ?x and ?y must be rdf:type of foaf:Person and distinct individuals for 
>> the arguments to be valid. One complication is that there is a matter of 
>> "in which graph or dataset(s) must these conditions hold"?
>> 
>> Maybe we could add a named graph parameter into the mix? With a 
>> URI-based named graph, we could use a syntax like “ex:ng??(?kb ?x ?y)”.
>> 
>> @prefix list:<http://www.w3.org/2000/10/swap/list# 
> <http://www.w3.org/2000/10/swap/list#>> .
>> 
>> @prefix log:<http://www.w3.org/2000/10/swap/log# <http://www.w3.org/2000/10/swap/log#>> .
>> 
>> @prefix ex:<http://example.org/# <http://example.org/#>> .
>> 
>> @prefix graph: <http://www.w3.org/2000/10/swap/graph# 
> <http://www.w3.org/2000/10/swap/graph#>> .
>> 
>> @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns# 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>> 
>> @prefix owl:<http://www.w3.org/2002/07/owl# <http://www.w3.org/2002/07/owl#>> .
>> 
>> ex:ng??(?kb ?x ?y) :graph
>> 
>> {
>> 
>> @requires ?kb holds { ?x rdf:type foaf:Person } .
>> 
>> @requires ?kb holds { ?y rdf:type foaf:Person } .
>> 
>> @requires ?kb holds { ?x owl:differentFrom ?y } .
>> 
>> ?x foaf:knows ?y .
>> 
>> ?y foaf:knows ?x .
>> 
>> } .
>> 
>> {
>> 
>> ex:ng??(:this ex:Alice ex:Bob) :graph ?graph .
>> 
>> ?graph graph:member ?stmt .
>> 
>> ?stmt log:equalTo { ?s ?p ?o } .
>> 
>> }
>> 
>> =>
>> 
>> {
>> 
>> ?s ?p ?o .
>> 
>> } .
>> 
>> Could those three "@requires" be a one-liner:
>> 
>> 
>> @prefix list:<http://www.w3.org/2000/10/swap/list# 
> <http://www.w3.org/2000/10/swap/list#>> .
>> 
>> @prefix log:<http://www.w3.org/2000/10/swap/log# <http://www.w3.org/2000/10/swap/log#>> .
>> 
>> @prefix ex:<http://example.org/# <http://example.org/#>> .
>> 
>> @prefix graph: <http://www.w3.org/2000/10/swap/graph# 
> <http://www.w3.org/2000/10/swap/graph#>> .
>> 
>> @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns# 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>> 
>> @prefix owl:<http://www.w3.org/2002/07/owl# <http://www.w3.org/2002/07/owl#>> .
>> 
>> ex:ng??(?kb ?x ?y) :graph
>> 
>> {
>> 
>> @requires ?kb holds { ?x rdf:type foaf:Person . ?y rdf:type foaf:Person 
>> . ?x owl:differentFrom ?y . } .
>> 
>> ?x foaf:knows ?y .
>> 
>> ?y foaf:knows ?x .
>> 
>> } .
>> 
>> {
>> 
>> ex:ng??(:this ex:Alice ex:Bob) :graph ?graph .
>> 
>> ?graph graph:member ?stmt .
>> 
>> ?stmt log:equalTo { ?s ?p ?o } .
>> 
>> }
>> 
>> =>
>> 
>> {
>> 
>> ?s ?p ?o .
>> 
>> } .
>> 
>> 
>> With something like those sketches, above, I’m hoping to express that 
>> the arguments provided must be as indicated, in this case two distinct 
>> people, as holding in a provided knowledgebase (a named graph or SPARQL 
>> endpoint, ?kb). The described graph-based template/macro/function would 
>> then produce a graph containing two statements: “?x foaf:knows ?y” and 
>> “?y foaf:knows ?x”.
>> 
>> It’s unclear what would or should happen if a template/macro/function 
>> were “invoked” with invalid arguments. Maybe it would or should, then, 
>> return an empty graph and/or maybe an error or exception would or should 
>> be thrown?
>> 
>> What is the construct in N3 with its variables? I think of it as a 
>> template/macro/function. The current approach to invocation involves a 
>> URI-based pattern which resembles binding arguments to parameters to 
>> invoke the template/macro/function.
>> 
>> What are the values which are bound to the variables? Thus far, I am 
>> using URIs (xsd:anyURI) in the sketches. In theory, the graph-based 
>> templates/macros/functions should work with built-in datatypes like 
>> strings (xsd:string) or numerical types (e.g., xsd:integer). So, the 
>> actual values bound to the variables are, thus far, URIs.
>> 
>> Hopefully this content, above, clarifies what I'm hoping to express in 
>> the sketches while also introducing some new possibilities.
>> 
>> Also, while I’m excited about the mapping which provides a means of 
>> accessing and utilizing query string portions of URIs, and about its 
>> potential uses with graph-based templates/macros/functions, one 
>> potential limitation of the approach is that there exists an upper limit 
>> on URI string length (2048 characters?).
>> 
>> Best regards,
>> 
>> Adam
>> 
>> 
>> ------------------------------------------------------------------------
>> *From:* David Booth <david@dbooth.org>
>> *Sent:* Wednesday, December 14, 2022 4:58 AM
>> *To:* Adam Sobieski <adamsobieski@hotmail.com>; semantic-web@w3.org 
>> <semantic-web@w3.org>
>> *Subject:* Re: Templates, Generics, and Parametric Polymorphism in 
>> Semantic Web Languages
>> Hi Adam,
>> 
>> I am not yet understanding how to interpret the examples you have given.
>>    To understand your suggested template syntax, I need an example to
>> clearly differentiate these 4-5 things:
>> 
>>     1. What is template prior to expansion?  (Think of this as a
>>        function.)
>>     2. Which parts of that template represent the variables
>>        that will be replaced with actual data during template expansion?
>>        (Think of these as the formal parameters to that function.)
>>     3. For each of those variables, what is the actual value
>>        to be substituted into the template, in place of that variable?
>>        (Think of these as the actual parameters to that function.)
>>     4. What is the final result of template expansion, after values
>>        have been substituted in for the variables?  (Think of these
>>        as the function result.)
>>     5. If you are also showing a syntax for invoking template expansion,
>>        then what part of the example is illustrating that?  (Think of this
>>        as showing the function invocation.)  The syntax needs to:
>>        a. identify the template to be expanded (like identifying the
>>           function to be called); and
>>        b. bind an actual value to each template variable (like binding
>>           an actual parameter to each formal parameter).
>> 
>> I assume that your example included some or all of the above, but it
>> isn't easy for me to see which bits are which.  Could you clarify please?
>> 
>> Thanks,
>> David Booth
>> 
>> On 12/14/22 00:12, Adam Sobieski wrote:
>>> Existing query-based solutions, e.g., SPIN, could be of use for 
>>> expressing the preconditions and effects of operators in planning 
>>> domains. Beyond the processing and inferencing functionalities of 
>>> solutions for templates and rules, there is the comparative 
>>> expressiveness of the templates and rules to consider, and also the ease 
>>> of consuming and inspecting the templates and rules to consider for each 
>>> solution. I am thinking about how convenient it can be made for 
>>> developers to utilize a more expressive planning domain definition 
>>> language / ontology and its resultant APIs and object models while 
>>> developing next-generation planning algorithms and solvers.
>>> 
>>> With respect to the proposed mapping for Semantic Web languages which 
>>> enables the access and use of URIs' query string portions, I recently 
>>> changed the syntax in the sketches and examples from “^^” (which had 
>>> some complications) to “??” (which I hope reminds developers of the URI 
>>> query string).
>>> 
>>> Understanding that "ex:ng??(ex:Alice ex:Bob)" maps to a URI, here is an 
>>> updated example of what a /named graph template/in N3 could resemble:
>>> 
>>> 
>>> @prefix list:<http://www.w3.org/2000/10/swap/list# 
>> <http://www.w3.org/2000/10/swap/list# 
> <http://www.w3.org/2000/10/swap/list#>>> .
>>> 
>>> @prefix log:<http://www.w3.org/2000/10/swap/log# <http://www.w3.org/2000/10/swap/log# 
> <http://www.w3.org/2000/10/swap/log#>>> .
>>> 
>>> @prefix ex:<http://example.org/# <http://example.org/# <http://example.org/#>>> .
>>> 
>>> @prefix graph: <http://www.w3.org/2000/10/swap/graph# 
>> <http://www.w3.org/2000/10/swap/graph# 
> <http://www.w3.org/2000/10/swap/graph#>>> .
>>> 
>>> ex:ng??(?x ?y) :graph
>>> 
>>> {
>>> 
>>> ?x rdf:type foaf:Person .
>>> 
>>> ?y rdf:type foaf:Person .
>>> 
>>> ?x foaf:knows ?y .
>>> 
>>> ?y foaf:knows ?x .
>>> 
>>> } .
>>> 
>>> {
>>> 
>>> ex:ng??(ex:Alice ex:Bob) :graph ?graph .
>>> 
>>> ?graph graph:member ?stmt .
>>> 
>>> ?stmt log:equalTo { ?s ?p ?o } .
>>> 
>>> }
>>> 
>>> =>
>>> 
>>> {
>>> 
>>> ?s ?p ?o .
>>> 
>>> } .
>>> 
>>> 
>>> I am brainstorming about other new uses of and scenarios for the mapping.
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Adam
>>> 
>>> 
>>> ------------------------------------------------------------------------
>>> *From:* David Booth <david@dbooth.org>
>>> *Sent:* Tuesday, December 13, 2022 5:16 PM
>>> *To:* semantic-web@w3.org <semantic-web@w3.org>
>>> *Subject:* Re: Templates, Generics, and Parametric Polymorphism in 
>>> Semantic Web Languages
>>> Since every rules language (including N3) in essence defines a template
>>> language for the rules, I think it's worth asking: why are the existing
>>> template facilities inadequate for my use cases, and how might they be
>>> extended to handle them?  If we can improve them to be more flexible,
>>> that may be better than adding more bandaids.
>>> 
>>> Bear in mind that SPARQL is also a commonly used "rules language", using
>>> either CONSTRUCT or INSERT.  ShExMap also acts as a rules language (and
>>> template language), as does SPIN.
>>> 
>>> David Booth
>>> 
>>> On 12/13/22 16:41, Adam Sobieski wrote:
>>>> Martin,
>>>> All,
>>>> Hello. I updated the Automated Planning and Scheduling Community Group's 
>>>> wiki to showcase /Reasonable Ontology Templates (OTTR)/: 
>>>> https://github.com/w3c-cg/planning/wiki/Ontologies 
> <https://github.com/w3c-cg/planning/wiki/Ontologies>
>> <https://github.com/w3c-cg/planning/wiki/Ontologies 
> <https://github.com/w3c-cg/planning/wiki/Ontologies>>
>>> <https://github.com/w3c-cg/planning/wiki/Ontologies 
>> <https://github.com/w3c-cg/planning/wiki/Ontologies 
> <https://github.com/w3c-cg/planning/wiki/Ontologies>>>
>>>> <https://github.com/w3c-cg/planning/wiki/Ontologies 
>>> <https://github.com/w3c-cg/planning/wiki/Ontologies 
>> <https://github.com/w3c-cg/planning/wiki/Ontologies 
> <https://github.com/w3c-cg/planning/wiki/Ontologies>>>> .
>>>> I am also interested in computation and Semantic Web technologies. I am 
>>>> thinking about inspectable, reflectable, reifiable, semantic templates, 
>>>> macros, and functions (see also: the Function Ontology (FnO)). It could 
>>>> be that the reification of language-integrated semantic templates and 
>>>> functions would involve OTTR and/or FnO models.
>>>> With respect to automated planning and scheduling, planning domains' 
>>>> operators' preconditions and effects can be represented as inspectable, 
>>>> reflectable, reifiable functions using Semantic Web technologies (in 
>>>> particular using n-ary semantic predicate calculus expressions).
>>>> 
>>>> Semantic templating can be of use for implementing generic types and 
>>>> functions, e.g,. "Widget<T>" and "function<T>(x, y, z)".
>>>> 
>>>> I am thinking about how best to represent conditional branching logic in 
>>>> semantic templates. These scenarios interest me in the contexts of 
>>>> planning domains and computer lexicons. Also interesting, with respect 
>>>> to OTTR, are patterns and compression.
>>>> Utilizing the mapping I shared, we could do new things. While I'm still 
>>>> thinking about the specific syntax (e.g., "^^" or "??"), we could now 
>>>> access and utilize the query string portions of URIs in Semantic Web 
>>>> languages. I'm arguing that this would be generally useful and that it 
>>>> would specifically benefit the technologies under discussion.
>>>> Best regards,
>>>> Adam
>>>> 
>>>> ------------------------------------------------------------------------
>>>> *From:* Martin Georg Skjæveland <martige@ifi.uio.no>
>>>> *Sent:* Tuesday, December 13, 2022 8:23 AM
>>>> *To:* william.vanwoensel@gmail.com <william.vanwoensel@gmail.com>; 
>>>> adamsobieski@hotmail.com <adamsobieski@hotmail.com>
>>>> *Cc:* doerthe.arndt@tu-dresden.de <doerthe.arndt@tu-dresden.de>; 
>>>> semantic-web@w3.org <semantic-web@w3.org>
>>>> *Subject:* Re: Templates, Generics, and Parametric Polymorphism in 
>>>> Semantic Web Languages
>>>> Hi,
>>>> 
>>>> there seems to be enough keyword matches to allow me to mention a
>>>> project that I have been working on, Reasonable Ontology Templates
>>>> (OTTR), see http://ottr.xyz <http://ottr.xyz> <http://ottr.xyz <http://ottr.xyz>> 
> <http://ottr.xyz <http://ottr.xyz <http://ottr.xyz>>>
>> <http://ottr.xyz <http://ottr.xyz <http://ottr.xyz <http://ottr.xyz>>>>.
>>>> 
>>>> OTTR is a template language for in particular RDF. It does not have all
>>>> the features you mention, its primary feature is to be able to
>>>> compactly represent complex statements as template instances that are
>>>> expanded via a simple recursive template expansion mechanim to plain
>>>> RDF.
>>>> 
>>>> Example; (using a modelling pattern from the Pizza ontology), this OTTR
>>>> template instance
>>>> 
>>>> [ ottr:of      <http://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
>>>> <http://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
>>> <http://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
>> <http://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
> <http://tpl.ottr.xyz/p/pizza/0.2/NamedPizza>>>>> ;
>>>>    ottr:values (x:argument1 x:argument2 (x:argument3-1 x:argument3-2))
>>>> ]
>>>> 
>>>> expands to:
>>>> 
>>>> x:argument3-1  a  owl:Class .
>>>> 
>>>> pz:hasTopping  a  owl:ObjectProperty .
>>>> 
>>>> x:argument1  rdfs:subClassOf  pz:NamedPizza ;
>>>>          rdfs:subClassOf  [ a                   owl:Restriction ;
>>>>                             owl:onProperty      pz:hasTopping ;
>>>>                             owl:someValuesFrom  x:argument3-1
>>>>                           ] ;
>>>>          rdfs:subClassOf  [ a                   owl:Restriction ;
>>>>                             owl:onProperty      pz:hasTopping ;
>>>>                             owl:someValuesFrom  x:argument3-2
>>>>                           ] ;
>>>>          rdfs:subClassOf  [ a               owl:Restriction ;
>>>>                             owl:hasValue    x:argument2 ;
>>>>                             owl:onProperty  pz:hasCountryOfOrigin
>>>>                           ] ;
>>>>          rdfs:subClassOf  [ a                  owl:Restriction ;
>>>>                             owl:allValuesFrom  [ a            owl:Class
>>>> ;
>>>>                                                  owl:unionOf  (
>>>> x:argument3-1 x:argument3-2 )
>>>>                                                ] ;
>>>>                             owl:onProperty     pz:hasTopping
>>>>                           ] .
>>>> 
>>>> x:argument3-2  a  owl:Class .
>>>> 
>>>> pz:hasCountryOfOrigin
>>>>          a       owl:ObjectProperty .
>>>> 
>>>> 
>>>> This example is found here: https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza>
>> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza>>
>>> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
>> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza>>>
>>>> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
>>> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
>> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza 
> <https://tpl.ottr.xyz/p/pizza/0.2/NamedPizza>>>>
>>>> More templates here: https://tpl.ottr.xyz/ <https://tpl.ottr.xyz/> <https://tpl.ottr.xyz/ 
> <https://tpl.ottr.xyz/>> <https://tpl.ottr.xyz/

>> <https://tpl.ottr.xyz/ <https://tpl.ottr.xyz/>>> <https://tpl.ottr.xyz/

>>> <https://tpl.ottr.xyz/ <https://tpl.ottr.xyz/ <https://tpl.ottr.xyz/>>>>
>>>> Playground here: https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/> 
> <https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/>>
>> <https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/>>>
>>> <https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/ <https://weblutra.ottr.xyz/>>>>
>>>> 
>>>> Cheers,
>>>> Martin
>>>> 
>>>> On Tue, 2022-12-13 at 12:59 +0000, Adam Sobieski wrote:
>>>>> William,
>>>>> All,
>>>>> 
>>>>> Thank you. This proposed language feature is generally useful and, in
>>>>> my opinion, merits consideration across Semantic Web languages (e.g.,
>>>>> N3, Turtle, TriG). I'm working on more concrete arguments
>>>>> here: https://github.com/w3c-cg/planning/discussions/27 
> <https://github.com/w3c-cg/planning/discussions/27>
>> <https://github.com/w3c-cg/planning/discussions/27 
> <https://github.com/w3c-cg/planning/discussions/27>>
>>> <https://github.com/w3c-cg/planning/discussions/27 
>> <https://github.com/w3c-cg/planning/discussions/27 
> <https://github.com/w3c-cg/planning/discussions/27>>>
>>>> <https://github.com/w3c-cg/planning/discussions/27 
>>> <https://github.com/w3c-cg/planning/discussions/27 
>> <https://github.com/w3c-cg/planning/discussions/27 
> <https://github.com/w3c-cg/planning/discussions/27>>>> .
>>>>> 
>>>>> Some clarifying key points:
>>>>>    1. There exists a bidirectional mapping between the proposed
>>>>> syntax and URIs/URLs with their query string portions utilized.
>>>>>    2. These URIs with their query string portions utilized can be
>>>>> used wherever a URI node or named graph can, across Semantic Web
>>>>> languages.
>>>>> 
>>>>> Expanding on point 1, the following:
>>>>> 
>>>>> ex:Widget^^(ex:Foo ex:Foo2 ex:Foo3)
>>>>> maps with:
>>>>> 
>>>>> http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget> <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget>> <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[ <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[>]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget>>> <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[ <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[>]=http%3A%2F%2Fexample.org%2F%23Foo2&T[ <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[ <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[>>]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[ <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[>]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org/?T[]=http%3A%2F%2Fexample.org%2F%23Foo&T[]=http%3A%2F%2Fexample.org%2F%23Foo2&T[]=http%3A%2F%2Fexample.org%2F%23Foo3#Widget>>>>
>>>>> and the following:
>>>>> 
>>>>> ex:Widget^^(("p1" ex:Foo) ("p2" ex:Foo2) ("p3" ex:Foo3))
>>>>> maps with:
>>>>> 
>>>>> http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget> <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget>> <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget>>> <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget <http://example.org?p1=http%3A%2F%2Fexample.org%2F%23Foo&p2=http%3A%2F%2Fexample.org%2F%23Foo2&p3=http%3A%2F%2Fexample.org%2F%23Foo3#Widget>>>>
>>>>> .
>>>>> 
>>>>> This mapping technique is recursive; templates' arguments can be
>>>>> templates.
>>>>> 
>>>>> This mapping technique is generally useful across Semantic Web
>>>>> languages and enables a number of interesting and useful features.
>>>>> Some of these envisioned features are powered by additional
>>>>> technologies, e.g., PHP and N3.
>>>>> 
>>>>> Pertaining to N3 specifically, while one could model templates and
>>>>> their parameters as you have indicated, the proposed solution enables
>>>>> N3 "named graph templates", with a rather nice syntactic sugar, as
>>>>> prototyped
>>>>> here: https://github.com/w3c-cg/planning/discussions/27#discussioncom 
> <https://github.com/w3c-cg/planning/discussions/27#discussioncom>
>> <https://github.com/w3c-cg/planning/discussions/27#discussioncom 
> <https://github.com/w3c-cg/planning/discussions/27#discussioncom>>
>>> <https://github.com/w3c-cg/planning/discussions/27#discussioncom 
>> <https://github.com/w3c-cg/planning/discussions/27#discussioncom 
> <https://github.com/w3c-cg/planning/discussions/27#discussioncom>>>
>>>> <https://github.com/w3c-cg/planning/discussions/27#discussioncom 
>>> <https://github.com/w3c-cg/planning/discussions/27#discussioncom 
>> <https://github.com/w3c-cg/planning/discussions/27#discussioncom 
> <https://github.com/w3c-cg/planning/discussions/27#discussioncom>>>>
>>>>> ment-4388356 .
>>>>> 
>>>>> While it's a work in progress, I'm excited about this one. Comments,
>>>>> questions, and feedback are welcomed!
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Adam
>>>>> 
>>>>> From: William Van Woensel <william.vanwoensel@gmail.com>
>>>>> Sent: Tuesday, December 13, 2022 6:48 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: Templates, Generics, and Parametric Polymorphism in
>>>>> Semantic Web Languages [Was Re: Syntactic Options for Probabilistic
>>>>> Semantics]
>>>>>  
>>>>> Hi Adam
>>>>> 
>>>>> Why introduce a new syntax (I believe you had a similar discussion
>>>>> before with Doerthe before on probabilities :-)
>>>>> 
>>>>> Unsure whether I fully understand your proposal - so feel free to
>>>>> criticize - but an option could just easily be:
>>>>>         ex:Widget tpl:parameters ( ex:Foo ex:Foo2 ex:Foo3 ) .
>>>>> Or
>>>>>         ex:Widget tpl:parameters ( [
>>>>>                 tpl:label “param1” ;
>>>>>                 tpl:value ex:Foo
>>>>>         ] [
>>>>>                 tpl:label “param2” ;
>>>>>                 tpl:value ex:Foo2
>>>>>         ] [
>>>>>                 tpl:label “param3” ;
>>>>>                 tpl:value ex:Foo3
>>>>>         ] ) .
>>>>> 
>>>>> A set of N3 rules could then directly operate on these parameters (as
>>>>> they are also written in N3) to instantiate the template.
>>>>> 
>>>>> 
>>>>> W
>>>>> 
>>>>> > On Dec 12, 2022, at 10:58 PM, Adam Sobieski
>>>>> > <adamsobieski@hotmail.com> wrote:
>>>>> > 
>>>>> > 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 
>>>> <http://www.example.org/#Widget 
>>> <http://www.example.org/#Widget 
>> <http://www.example.org/#Widget 
> <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 
>>>> <http://www.example.org/#Widget 
>>> <http://www.example.org/#Widget 
>> <http://www.example.org/#Widget 
> <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#Wi

>>>>> > dget” 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 
> <https://github.com/w3c-cg/planning/discussions/21>
>> <https://github.com/w3c-cg/planning/discussions/21 
> <https://github.com/w3c-cg/planning/discussions/21>>
>>> <https://github.com/w3c-cg/planning/discussions/21 
>> <https://github.com/w3c-cg/planning/discussions/21 
> <https://github.com/w3c-cg/planning/discussions/21>>>
>>>> <https://github.com/w3c-cg/planning/discussions/21 
>>> <https://github.com/w3c-cg/planning/discussions/21 
>> <https://github.com/w3c-cg/planning/discussions/21 
> <https://github.com/w3c-cg/planning/discussions/21>>>> [2]
>>>>> > https://github.com/seanmorris/php-wasm 
> <https://github.com/seanmorris/php-wasm>
>> <https://github.com/seanmorris/php-wasm 
> <https://github.com/seanmorris/php-wasm>>
>>> <https://github.com/seanmorris/php-wasm 
>> <https://github.com/seanmorris/php-wasm 
> <https://github.com/seanmorris/php-wasm>>>
>>>> <https://github.com/seanmorris/php-wasm 
>>> <https://github.com/seanmorris/php-wasm 
>> <https://github.com/seanmorris/php-wasm 
> <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 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R>
>> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R>>
>>> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
>> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R>>>
>>>> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
>>> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
>> <http://ppr.cs.dal.ca:3002/n3/editor/s/ztVCkf2R 
> <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#discussi

>>>>> > > oncomment-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): 
> <https://github.com/w3c/rdf-star/issues/276):>
>> <https://github.com/w3c/rdf-star/issues/276): 
> <https://github.com/w3c/rdf-star/issues/276):>>
>>> <https://github.com/w3c/rdf-star/issues/276 
> <https://github.com/w3c/rdf-star/issues/276>):
>> <https://github.com/w3c/rdf-star/issues/276): 
> <https://github.com/w3c/rdf-star/issues/276):>>>
>>>> <https://github.com/w3c/rdf-star/issues/276 
>> <https://github.com/w3c/rdf-star/issues/276 
> <https://github.com/w3c/rdf-star/issues/276>>):
>>> <https://github.com/w3c/rdf-star/issues/276 
> <https://github.com/w3c/rdf-star/issues/276>):
>> <https://github.com/w3c/rdf-star/issues/276): 
> <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 
>>>> <https://w3c.github.io/N3/spec/#changes-since-team-submission 
>>> <https://w3c.github.io/N3/spec/#changes-since-team-submission 
>> <https://w3c.github.io/N3/spec/#changes-since-team-submission 
> <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 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T>
>> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T>>
>>> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T 
>> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T 
> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T>>>
>>>> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T 
>>> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T 
>> <http://ppr.cs.dal.ca:3002/n3/editor/s/RfwLWp8T 
> <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
>>>>> 
>>>>> 
>>>> 
>>> 

Received on Saturday, 17 December 2022 12:51:32 UTC