Position of quantifiers

Current situation

The following N3

{:s :p1 :o1} => {:RULE1 :has :fired}.
@forAll :s.
{:s :p2 :o2} => {:RULE2 :has :fired}.

is processed differently by EYE and CWM.

EYE interprets it as

{:s :p1 :o1} => {:RULE1 :has :fired}.
{?U_0 :p2 :o2} => {:RULE2 :has :fired}.

CWM raises an error

ValueError: Internal error: declareUniversal: s?

Options

Allow quantifiers only at the beginning of a formula

More precisely, they would be allowed only:

• between the beginning of the file and the first triple of that file, and
• between an opening bracket and the first triple inside this bracket.

Pros:

• easier for parsers
• no risk to accidentally change the meaning of an IRI in the middle of a file

Cons:

• will probably cause much backward compatibility issues
• having all variables declared at the top can be cumbersome, compared to declaring variables just before they are used

Allow quantifiers anywhere, but raise an error if the quantified IRI was used before

This is what CWM currently does.

Pros

• same as "Quantifiers only at the top", with more flexibility

Cons

• ...

Allow quantifiers anywhere, and interpret them as if they were at the top of the formula

Pros

• quantifiers would be treated as triples in the sense that the position they occur does not matter

Cons

• this forces parsers to re-evaluate all the previously parsed triples once a quantifier is encountered
• this could cause confusion for implementers

Allow quantifiers anywhere, and treat differently the triples before the quantifier and those after it

This is what EYE currently does.

Pros

• easy to parse

Cons

• may be confusing for people reading N3 files

Note about file concatenation and copy-paste

Turtle (and its derived syntaxes) is designed in such a way that concatenating two valid Turtle files yields a valid Turtle file, whose meaning is the conjunction of the original files. The order in which the files are concatenated has not impact.

The same will not be true of N3. The same IRI can be considered as a constant in one file, and a quantfied variable in another file. Depending on the order of the concatenation (and the option chosen for handling quantifiers), the resulting concatenation may change the semantics of the constant IRI, or yield an invalid N3 file.

It also means that copy-pasting a piece of an N3 file into another N3 file must be done with caution.

Add variable name-space declaration

Another option to address the problems above could be to explicitly declare a namespace as variable namespace. Instead of

@prefix ex: http://www.example.org#.

we could allow something like

@var ex: http://www.example.org#.

in order to indicate that we will use the indicated namespace for our variables.

Pros

• makes it easier to detect conflicts for example between concatenate files (the same prefix should not be declared as normmal prefix and as var prefix at the same time)

Cons

• adds more complexity to the language