- From: Tanel Tammet <Tanel.Tammet@ttu.ee>
- Date: Mon, 31 Aug 2020 22:34:50 +0300
- To: Gregg Kellogg <gregg@greggkellogg.net>, Dominik Tomaszuk <ddooss@wp.pl>
- Cc: public-rdf-dev@w3.org, Semantic Web <semantic-web@w3.org>, public-webapps@w3.org, Linked JSON <public-linked-json@w3.org>
- Message-ID: <90228568-6338-6a62-6faf-84951fa3e77b@ttu.ee>
Thank you for the pointers! Had a fresh look at the N3 progress: I do believe in the same goals, with a particular interest in representing uncertain knowledge. An approach I have found useful is to think about semantics in the terms of a concrete translation to standard FOL, plus concrete metalogical extensions to FOL like you need for representing uncertainties. Considering the efficiency of reasoners, it really boils down to finding a search strategy suited for the problem, while the specific representation issues are less important. Practically speaking, creating parsers (and then updating them) is quite a pain, hence a concrete JSON representation would help. I was trying to understand the cited formulas / metadata in N3 with that view: what would be the suitable FOL translation and additional machinery. For example, :LoisLane :believes { :Superman :can :fly }. I understand a simple pure FOL approach would be taking { :Superman :can :fly } as a quad with a new id, say, _:i1, and then say :LoisLane :believes _:i1. But then we need to reason with that, which becomes conceptually nontrivial. For probabilistic annotations I do not believe that a strict FOL translation is suitable, but a good approach is to have explicit metadata on top of FOL formulas, which then requires concrete rules for operating with this metadata on top of conventional FOL proofs. For probabilities it works out OK via many-worlds semantics, if you do not become too greedy with representation capabilities. Perhaps it works out similarly for some other kinds of metadata. For example, I have no idea how to practically combine FOL with uncertainties once you allow to give probabilities to conjunctions, while I have an OK understanding of how to reason efficiently if you only allow to assign probabilities to disjunctions of literals, i.e. clauses. What is your take on representing and inferring with metadata? Tanel Tammet tanel.tammet@ttu.ee On 2020-08-31 8:20 p.m., Gregg Kellogg wrote: > I’ve been spending a lot of time on Notation3 lately, and one of my > objectives is to define an adequate abstract syntax for Notation3, > such that a variation on JSON-LD could emit triples in that syntax. > (Note generalized datasets defined in RDF Concepts [1] are a good > start towards this). This basically means using first-class list > resources, introducing quantified variables, treating named graphs as > embedded formula and allowing any resource in any position (with > restrictions on properties, due to syntax considerations, likely). A > conforming Notation3 reasoner could then operate on the results of > parsing JSON-LD into this syntax, emit results as JSON-LD, and allow > interoperability with rules defined in N3. > > JSON-LD anonymous named graphs are already very much like formulae, > given the way the graph value of a property (@conatiner: @list) > creates a blank node which is both the value of that property and the > name of an associated named graph. > > There have been calls for first-class collections in RDF before, and > Notation3 shows how important they can be. They are used in argument > lists to builtins, and representing as first/rest chains interferes > with the existential quantification property of blank nodes, and makes > BGP matching of antecedent formulae using these lists impractical. > > The proposed spec for JSON-LD* [2] already provides a mechanism for > creating a triple as the value of @id, and extending this ability to > allow for literals and lists could follow on that work. > > Gregg Kellogg > gregg@greggkellogg.net <mailto:gregg@greggkellogg.net> > > [1] https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf > <https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf> > [2] https://json-ld.github.io/json-ld-star/ > <https://json-ld.github.io/json-ld-star/> > >> On Aug 31, 2020, at 7:34 AM, Dominik Tomaszuk <ddooss@wp.pl >> <mailto:ddooss@wp.pl>> wrote: >> >> W dniu 31.08.2020 o 12:57, Tanel Tammet pisze: >>> Hi, >>> Maybe you are interested of a fresh JSON-LD-compatible draft >>> proposal for the JSON format of logic for provers: >>> https://github.com/tammet/json-ld-logic >>> <https://github.com/tammet/json-ld-logic> >>> There is a live pure-browser prover playground for the syntax >>> http://logictools.org/json.html >>> running my https://github.com/tammet/gkc prover using Wasm. >>> Any comments and suggestions would be most welcome! >>> Regards, >>> Tanel Tammet >> >> Hi Tanel, >> >> I invite you to a similar project: Notation3. >> >> https://github.com/w3c/N3 <https://github.com/w3c/N3> >> >> Best, >> >> -- >> Dominik Tomaszuk >> Research Fellow >> University of Bialystok >> Poland >> >
Received on Monday, 31 August 2020 19:35:18 UTC