Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Formula term #37

Open
jeswr opened this issue Jun 2, 2023 · 7 comments
Open

Proposal: Formula term #37

jeswr opened this issue Jun 2, 2023 · 7 comments

Comments

@jeswr
Copy link
Contributor

jeswr commented Jun 2, 2023

I would like to propose the introduction of a new RDF/JS term called a Formula to represent Notation3 Formulas / Graph Terms.

Currently, when Notation3 syntax is parsed, Graph Terms in Notation3 are represented using blank nodes. That is,

:a :b { :c :d :e } . 

will be parsed as the two quads

:a :b _:b0
:c :d :e _:b0

The fact that _:b0 represents a graph term and not a blank node in :a :b _:b0 cannot be deduced from the triple alone. Instead it has to be implicit from the presence of the quad :c :d :e _:b0 in a dataset; where _:b0 is used as a graph term.

Furthermore, empty graphs are legal in N3. That is, the statement :a :b {} . is legal in N3. This gets parsed to the RDF/JS quad :a :b _:b0 which is the same as parsing :a :b [] despite :a :b {} and :a :b [] having an entirely different semantic meaning. This means that without having a notion of Notation3 Formulas / Graph Terms, or at least the empty graph, we are enable to represent all N3 concepts within RDF/JS.

@phochste
Copy link

phochste commented Jun 3, 2023

For the empty graph it would be sufficient to parse it as true :a :b {} is isomorphic to :a :b true. See also https://w3c.github.io/N3/spec/semantics.html#ground-graphs .

@jeswr
Copy link
Contributor Author

jeswr commented Jun 4, 2023

or the empty graph it would be sufficient to parse it as true :a :b {} is isomorphic to :a :b true.

I'm not entirely sure on this. Note that a parser should deal only with converting syntax to a set of triples and generally not be aware of any semantics that reasoners apply. So I am not sure if {} should be parsed as true in the same way that ex:me should not be parsed as ex1:me even if ex:me owl:sameAs ex1:me.

If the spec were explicit in saying that {} should be parsed as the literal true then I would be ok with this.

I'd be interested to see what @josd thinks of this.

@phochste
Copy link

phochste commented Jun 4, 2023

in the same way that ex:me should not be parsed as ex1:me even if ex:me owl:sameAs ex1:me.

I think this owl:sameAs is on yet another level (already an inference). The true of the empty graph is on model level. But, you are right that this is already interpreting the data in some way. Interestingly, it depends on the implementation.

@josd
Copy link

josd commented Jun 4, 2023

In eye we treat {} as true because the empty conjunction of triples is true.

@rubensworks
Copy link
Member

Since N3 is not (on its way to become) a W3C rec yet, I'm not sure if it's the right time to add this to the core datamodel yet of RDF/JS.
An alternative would be for the N3 CG to propose an extension of the RDF/JS Term, and standardize it in the context of the N3 CG?

@bergos
Copy link
Member

bergos commented Jun 5, 2023

If treating {} as true, as proposed by @josd, is possible without drawbacks, I would support that solution. That would avoid the problems mentioned by @rubensworks.

Btw. These kind of topics should be discussed in the repository of the Data Model specification. If there is more to discuss, please move the discussion there. In case the solution with true works, it would be good to have a summary somewhere. Maybe you can create a new N3 page in the Wiki.

@jeswr
Copy link
Contributor Author

jeswr commented Jun 5, 2023

If treating {} as true, as proposed by @josd, is possible without drawbacks, I would support that solution.

I'm deferring this decision to the N3 group. If we see a syntax test case where the test case is :a :b {} and the expected output is :a :b true then we can close of this issue and I will create a wiki page.

Otherwise I will move the discussion to the Data Model specification repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants