- From: Tanel Tammet <Tanel.Tammet@ttu.ee>
- Date: Wed, 2 Sep 2020 22:01:01 +0300
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: public-n3-dev@w3.org
- Message-ID: <d6aa4cdb-30f9-1828-4af3-0642aca28cb4@ttu.ee>
Thanks, happy to join the Skype meetings.
>
> I see your proposal as using JSON-LD as a carrier of information,
> rather than leveraging the RDF data model, itself.
Right. But, of course, the RDF data model is a subset of FOL and the
JSON-LD interpretation is preserved for data unless we decide to replace
parts of it (like the proposed lists as terms) in specific places. The
proposed model does not encode logical formulas as triplets like OWL
does, but this does not contradict JSON-LD, since there are no logical
formulas in that language anyway.
> Notation-3 does this by adding quantified variables, quoted and
> quantified graphs, and predicates that are given specific
> interpretation as builtings (e.g., log:implies) to the RDF Abstract
> Syntax. One recent example from Doerthe relates to the superman issue [2].
A good concrete example. I'll think a bit about the JSON-LD
interpretation you propose here.
Hopefully I understand correctly that the current N3 spec says that
cited formulas are NOT referentially transparent, and the example below
contains a specific axiom basically saying that LoisLane believing
something about any object IS referentially transparent, kind of an
exception axiom to the general non-transparency principle.
Regards,
Tanel
>
> :LoisLane :believes {:Superman :can :fly.}.
>
> :Superman owl:sameAs :ClarkKent.
>
> { :LoisLane :believes {?s1 ?p1 ?o1}. ?s1 owl:sameAs ?s2. } =>
> {:LoisLane :believes {?s2 ?p1 ?o1}.}.
>
>
> which would result in the following:
>
> :LoisLane :believes {:ClarkKent :can :fly}.
>
>
> By my thinking, that might be represented in a JSON-LD variation as
>
> [{
> "@id": "LoisLane",
> "believes": {"@graph": { "@id": "Superman", "can": "fly"}}
> }, {
> "@id": "Superman",
> "owl:sameAs" "ClarkKent"
> }, {
> "@graph": [{
> "@id": "LoisLane",
> "believes": {"@graph": {"@id": "?s1", "?p1": "?o1"}},
> }, {
> "@id": "?s1",
> "owl:sameAs": "?s2"
> }],
> "log:implies": {
> "@graph": {
> "@id": "LoisLane",
> "believes": {"@graph": {"@id": "?s2", "?p1": "?o1"}}
> }
> }
> }]
>
>
> Of course, this could be made more compact by declaring “believes” and
> “log:implies” to have “@container”: “@graph” and aliasing “=>” to
> “log:implies” and “=“ to “owl:sameAs”..
>
> Gregg Kellogg
> gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>
>
> [1] https://www.w3.org/community/n3-dev/
> <https://www.w3.org/community/n3-dev/>
> [2] https://github.com/w3c/N3/issues/8#issuecomment-508159508
> <https://github.com/w3c/N3/issues/8#issuecomment-508159508>
>
>
>> On Aug 31, 2020, at 12:34 PM, Tanel Tammet <Tanel.Tammet@ttu.ee
>> <mailto:Tanel.Tammet@ttu.ee>> wrote:
>>
>> 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 Wednesday, 2 September 2020 19:01:21 UTC