These are chat archives for rdfjs/public

9th
May 2017
webr3
@webr3
May 09 2017 00:44
does N3.js support implies, variables, and quantification?
elf Pavlik
@elf-pavlik
May 09 2017 01:56
I guess question to @RubenVerborgh
Ruben Verborgh
@RubenVerborgh
May 09 2017 07:20
@webr3 Yes, but you need to specify the format explicitly in any of the following ways:
var parser3 = N3.Parser({ format: 'N3' });
var parser4 = N3.Parser({ format: 'Notation3' });
var parser5 = N3.Parser({ format: 'text/n3' });
webr3
@webr3
May 09 2017 12:02
@RubenVerborgh that is most awesome!
side note: it seems a bit odd that N3 isn't the default for N3.js
N3 is what we need, and only has one concrete syntax, v easy to work with compared to the plethora of piggybacked rdf types
it'll be a lot easier to use, explain, and maintain, if N3 is just the default, with support for the other media types to be read and converted to N3, since they are subsets
webr3
@webr3
May 09 2017 12:09
some context - when doing rdf-interfaces, this is what I wanted to do, have full n3 support, multiple graphs etc, but had to cut it all out to align with rdf at the time - so very glad you're having another stab at it with said support - I'd strongly advocate just being an n3 lib and spec, with rdf for backwards compatibility
way nicer to actually work with graphs, and think in graphs, than linked trees shoehorned in to heirarchical closed world assuming types
webr3
@webr3
May 09 2017 12:14
strongly considering doing an n3 1.1/2 spec and implementation in stealth mode - maybe with sets, certainly with a few basic types added like datetime
I had a crack with jsn3 a few years ago, but see now this was the wrong approach, adding n3 semantics to json - it needs to be first class graph notation, not added to object notation
Ruben Verborgh
@RubenVerborgh
May 09 2017 13:12

side note: it seems a bit odd that N3 isn't the default for N3.js

Yeah, well, N3.js was created before Turtle was standardized. The problem is that N3 is still not standardized, and, worse, that the graph interpretation of TriG is incompatible with that of N3.

it'll be a lot easier to use, explain, and maintain, if N3 is just the default,

I highly doubt that, given that N3 is not standardized.

other media types to be read and converted to N3, since they are subsets

I wish they were… :'(

elf Pavlik
@elf-pavlik
May 09 2017 14:47
hi @webr3 glad to see you here! @RubenVerborgh and @timbl discussed in RDF/JS chatroom some time ago possibility to put efforts toward N3 standard but I haven't heard anything about it since then

The problem is that N3 is still not standardized, and, worse, that the graph interpretation of TriG is incompatible with that of N3.

did someone documented it? if yes sharing a link much appreciated :)

webr3
@webr3
May 09 2017 16:09
@RubenVerborgh N3 will be standardized (beyond a team submission) if people gather around it and decide it is useful, and indeed use it.
if you focus on the RDF types, you are perpetuating the status quo
N3 is better, simpler, more powerful, and more useful

The problem is that N3 is still not standardized

This is not a problem, conversely it's a freedom - you don't HAVE to use standards, you want to use good technologies, and standards come about when lots of people use a technology - use then standardize, not standardize then use

webr3
@webr3
May 09 2017 16:18
could easily argue that RDF being an abstract syntax was a product of environment and it going through as RDF/XML which didn't model it fully, and it's just went further off course ever since shoehorned in to everything
N3 is a single syntax, I personally view it as liberated and unconstrained - if people gather around it, it will just be graph notation for the web
Adrian Gschwend
@ktk
May 09 2017 16:34
wow hi @webr3
long time no see :)
Ruben Verborgh
@RubenVerborgh
May 09 2017 16:45

did someone documented it?

I'll do it here :-) So some minor syntax incompatibilities (unicode-related, and which chars are allowed in qnames), but the major thing is the interpretation of blank nodes. For N3, blank node scope is graph; for TriG, blank node scope is document.

N3 will be standardized (beyond a team submission) if people gather around it and decide it is useful, and indeed use it.

If, indeed. I'm hoping hard for that. In any case, the other syntaxes are standardized and more widespread (in terms of number of triples), so that's my default. My guess is that, when standardized, N3 will have to follow the others and not the other way round.

if you focus on the RDF types, you are perpetuating the status quo
N3 is better, simpler, more powerful, and more useful

N3 is not better nor simpler, and hence not more useful. For just one of its issues with simplicity, see https://ruben.verborgh.org/publications/arndt_ruleml_2015/
It is more powerful.

N3 is a single syntax, I personally view it as liberated and unconstrained - if people gather around it, it will just be graph notation for the web

N-Quads and TriG are taking that role now.

webr3
@webr3
May 09 2017 16:49
now existential quantification has scope?
Ruben Verborgh
@RubenVerborgh
May 09 2017 16:49
Certainly. _:x means different things in different documents (or graphs, if N3).
webr3
@webr3
May 09 2017 16:52
nah, it just means _:x exists, you can say it twice and it is redundant
if it exists as per document it exists as per graph
Ruben Verborgh
@RubenVerborgh
May 09 2017 16:52
let me make that clearer, just a sec
MacRuben:tmp$ cat test.n3
<Tom> a :Cat.
{ _:x a :Cat. } => { _:x a :Mammal }.
MacRuben:tmp$ cwm test.n3 --think
#Processed by Id: cwm.py,v 1.197 2007/12/13 15:38:39 syosi Exp
        #    using base file:///private/tmp/test.n3

#  Notation3 generation by
#       notation3.py,v 1.200 2007/12/11 21:18:08 syosi Exp

#   Base was: file:///private/tmp/test.n3
     @prefix : <#> .

    <Tom>     a :Cat .
      [      a :Mammal ].
    {

          [      a :Cat ].

        }     <http://www.w3.org/2000/10/swap/log#implies> {
          [      a :Mammal ].
        } .

#ENDS
so different _:x in both formulas
now try _:x in different graphs in a TriG document; you'll see they're the same
webr3
@webr3
May 09 2017 16:56
_:x just means exists?
Ruben Verborgh
@RubenVerborgh
May 09 2017 16:56
it's about the identifier
webr3
@webr3
May 09 2017 16:56
identifier is meaningless?
Ruben Verborgh
@RubenVerborgh
May 09 2017 16:56
in TriG, that _:x is the same thing for the whole document
in N3, it's a different thing per graph
meaningless, but used to tell if things are the same
N3 and TriG differ in their definitions of when blank node identifiers point to the same thing
so that's rather problematic
webr3
@webr3
May 09 2017 16:57
I will look at this
Ruben Verborgh
@RubenVerborgh
May 09 2017 16:58
good, keep us updated
you should come to the same conclusion as I did; it's in the TriG spec, and implemented in EYE and cwm
and my guess is that N3 will adapt if ever standardized for that reason
webr3
@webr3
May 09 2017 17:17
I see the serializations are different
but I don't see implementation issue, can you point to it?
webr3
@webr3
May 09 2017 17:39
(in code)
webr3
@webr3
May 09 2017 18:35
nope I'm definitely missing something here, your example used existential quantification (bnodes) instead of universally quantified variables. the results were as expected, the test.n3 doc would be better written with ?x instead of _:x
it's Trig that's messed up by quantifying bnodes wrong
trig uses _:x when they mean :x / ?x
@RubenVerborgh see above @timbl pls confirm
webr3
@webr3
May 09 2017 18:44
it is useful to be able to imply that a mammal exists if a cat does, it is also useful to be able to say that if something is a cat it is a mammal, this is why bnodes and variables exist in n3, to allow both
trig is missing variables, and has overloaded bnodes
in n3.js of a bnode label exists in more than one trig graph, convert it to a variable
if*
is this the same conclusion you came to?
webr3
@webr3
May 09 2017 19:00
Ruben, if you document the rest of the inconsistencies, or perhaps I can just work it out, an n3 1.1 should be a minor revision - not to be negative but I don't feel like there's a huge amount if n3 out there, let alone stuff that'd be backwards incompatible - and if there was, it'd be a pleasant surprise
Ruben Verborgh
@RubenVerborgh
May 09 2017 19:59

the results were as expected

Given N3 semantics, yes.

the test.n3 doc would be better written with ?x instead of _:x

But then the meaning would change of course.

Trig that's messed up by quantifying bnodes wrong

No, they just define a different scope (as in point 1 of https://www.w3.org/TR/trig/#grammar-ebnf). TriG standardized it this way before N3, so unfortunately, they decide on what is "right".
N3 doesn't even fully specify its scope, hence https://ruben.verborgh.org/publications/arndt_ruleml_2015/.

trig is missing variables

The RDF model is, really.

and has overloaded bnodes

As you said before; they're just identifiers. TriG set their scope to a document.

in n3.js if a bnode label exists in more than one trig graph, convert it to a variable
is this the same conclusion you came to?

No, my conclusion was to do the opposite: when parsing N3, every blank node in another formula is a new occurrence, hence gets a different label. Blank node labels in N3.js are unique over the entire scope of a program.

if you document the rest of the inconsistencies, or perhaps I can just work it out, an n3 1.1 should be a minor revision

That's definitely possible; I'll be staying at MIT with @timbl 3 months during summer, so could be something good to have a look at. Essentially, I think that N3 should be defined as a strict superset of Turtle (right now, there's unicode differences, PREFIX, BASE, …), and my dream would be to have N3 as a superset of TriG.

not to be negative but I don't feel like there's a huge amount if n3 out there, let alone stuff that'd be backwards incompatible - and if there was, it'd be a pleasant surprise

Depending on what the suggested fix is, it might or might not give backward compatibility issues :-) If we want alignment with TriG, it'll make all rulesets with blank nodes unusable.

Tim Berners-Lee
@timbl
May 09 2017 20:10
@webr3 @RubenVerborgh Yes @webr3 that example from @RubenVerborgh was strange — it was an abuse of N3 in a way to write:
<Tom> a :Cat.
{ _:x a :Cat. } => { _:x a :Mammal }.
You would normally say
<Tom> a :Cat.
{ ?x a :Cat
. } => { ?x a :Mammal }.
In a rule, the variables have to universally quaniified as in “for all” as oppsed to existentally.
The top one here does have a meaning, it says “If there a something which is a cat then there is sometthing which is a mamal”. The bottom one is more useful, meaning “if something x is a cat then that something x is a mamal"
Tim Berners-Lee
@timbl
May 09 2017 20:16
The trick in N3 is that ?x are UNIVERSALLY quanitified at the PARENT graph level (in that case the document). _x: is like [ … ] and is EXISTENTIALLY quantified in the LOCAL graph. If you need more control hen you can be explict with @forAll and @forSome keywords.
<Tom> a :Cat.
{ ∃x. _:x a :Cat. } => {∃x. _:x a :Mammal }.
compared with
∀x 
  <Tom> a :Cat.
   { ?x a :Cat
  . } => { ?x a :Mammal }.
Tim Berners-Lee
@timbl
May 09 2017 20:22
to mix n3 and normal logic to explain.
@RubenVerborgh "TriG standardized it this way before N3, so unfortunately, they decide on what is “right” Trig may have become a standrad in some sense more recently but that is not impressive as Trig was invented long time after N3 was invented and is doesn’t do everything N3 does — I didn’t pay much attetion to Trig as I didn’t need it as I had N3.
Tim Berners-Lee
@timbl
May 09 2017 20:29
If Trig has made different and its own choices — does N3 have to be try to be compatible? What sort of things is Trig used for? Anythng which cannot be done with N3?
webr3
@webr3
May 09 2017 20:32
it can easily be coded around, trig has overloaded bnodes to specify then as universally quantified when they exist in more than one graph. so in our libraries we simply convert the bnodes to a variable in this case, and correct/formalise the overloading
@RubenVerborgh if you have chosen to do the opposite, do not call it n3.js and do not say it fully supports n3, call it an rdf library that partially supports n3
there is too much conflation already
rdf was standardized to be XML compatible and got an abstract syntax and subset of n3
view n3 as the goal, and rdf as the stepping stone that allows data to be published on the web :) which is useful, but different
Ruben Verborgh
@RubenVerborgh
May 09 2017 20:38

@timbl Yeah, my example was abuse indeed; just wanted to show the scope of _:x there as compared to TriG.

TriG is just quads and meant more for "scoping" triples. I guess what one would do in N3 as <g> = { _:x a <Cat>. }., with slightly different semantics. (In N3, this would list the complete graph <g>, whereas in TriG, <g> { _:x a <Cat>. } might or might not be the complete graph.)

If Trig has made different and its own choices — does N3 have to be try to be compatible?

It might be confusing otherwise, given the very similar syntax.

@webr3

if you have chosen to do the opposite, do not call it n3.js and do not say it fully supports n3,

I call it N3.js. It fully supports N3. And it does the opposite of what you said above, but the same of what EYE and cwm do.

But, maybe just for clarity: I think TriG did it wrong. They should have followed N3 regarding scoping of blank nodes. Yet the ship has sailed (and I noticed too late).
webr3
@webr3
May 09 2017 20:55
it was made clear to those working on TriG and RDF years ago that this was wrong, but the decision was made anyway
you do not have to change TriG or N3, but you can change n3.js, which I believe you develop, to simply swap trig bnodes to variables at run time if they exist in more than one graph, then you are compatible with both :)
it will also help you serialize again (if you do this) since you will know to give the variables the same _:name in different graphs within the same trig document
Ruben Verborgh
@RubenVerborgh
May 09 2017 20:57
Once the TriG/N3 is parsed, there is no problem really.
webr3
@webr3
May 09 2017 20:57
so is the problem in the parsing, or is there no problem?
Ruben Verborgh
@RubenVerborgh
May 09 2017 20:57
For in-memory representation of triples/quads, a simple truth holds: identifiers equal = same node.
I've solved the problem in the parser, and I've solved it the way cwm and EYE do it.
webr3
@webr3
May 09 2017 21:00

For in-memory representation of triples/quads, a simple truth holds: identifiers equal = same node.

boolean .equals(Term other) returns true if and only if other has termType "BlankNode" and the same value.

Ruben Verborgh
@RubenVerborgh
May 09 2017 21:01
yeah, I was talking about N3.js identifiers, not RDF/JS identifiers. But N3.js will eventually migrate to the latter.
So then, same thing.
webr3
@webr3
May 09 2017 21:03
and you view this as the correct thing to do, and to provide as tooling, even though:
a) it has been made clear that it is incorrect
b) you have also said that you feel it is incorrect in Trig
i.e. you are happy to sail another ship with a known error?
I don't need to know the answer :) and I appreciate your time, thank you @RubenVerborgh
Ruben Verborgh
@RubenVerborgh
May 09 2017 21:04
Again, N3.js' interpretation is not incorrect. EYE, cwm, and N3.js will parse { _:x <p> <o> } => { _:x <p> <o> } as { [ <p> <o> ] } => { [ <p> <o> ] }.
And what N3.js does in-memory is independent of what concrete syntaxes do.
webr3
@webr3
May 09 2017 21:07

the major thing is the interpretation of blank nodes. For N3, blank node scope is graph; for TriG, blank node scope is document.

please confirm, does N3.js scope blank nodes to graph (formulae) or to document? (for text/n3)

Ruben Verborgh
@RubenVerborgh
May 09 2017 21:13

for text/n3, N3.js scopes blank nodes to formulae. That's what I meant above with:

my conclusion was to do the opposite: when parsing N3, every blank node in another formula is a new occurrence, hence gets a different label.

webr3
@webr3
May 09 2017 21:16
okay, and do you think this needs to change?
Ruben Verborgh
@RubenVerborgh
May 09 2017 21:26
I just think it would be nice if TriG and N3 aligned about the scope of blank nodes. Since TriG is standardized and thus cannot change, the only option to realize such an alignment is to change N3. (Not a necessity, but a very nice to have.)
webr3
@webr3
May 09 2017 21:34
why is it nice to have?
how would you even serialize N3 to TriG?
Austin Wright
@awwright
May 09 2017 22:23
Oh hey, webr3 is back