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

Received on Monday, 12 December 2022 14:36:22 UTC