N3Parser should allow literal subjects

[tibotiber]

Hi Ruben,

It seems that the store accepts literals only for objects, it will refuse them for subjects right? This made my application crash when loading the store with triples parsed from EYE inference results using the following rule.

{?P rdfs:range ?C. ?X ?P ?Y} => {?Y a ?C}.

I have solved it by modifying the rule to

{?P rdfs:range ?C. ?X ?P ?Y. ?Y log:rawType ?T. ?T owl:differentFrom rdfs:Literal} => {?Y a ?C}.

I was wondering whether it would be better to make the store more permissive on this aspect. What do you think?

Thibaut.

[akuckartz]

An RDF triple consists of three components:
the subject, which is an IRI or a blank node
the predicate, which is an IRI
the object, which is an IRI, a literal or a blank node

http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-triples

[RubenVerborgh]

@tibotiber As @akuckartz says, subjects and predicates cannot be literals in RDF.

However, do you have a reference whether they are allowed in N3?
It might be that N3 allows them (as it extends the RDF model).

[akuckartz]

There is a table with a header "Literal subj" which indicates that N3 allows literals as subjects
http://www.w3.org/TeamSubmission/n3/#subsets
(That specifiation is only a W3C Team Submission)

[RubenVerborgh]

Indeed, I think I'll allow that too then. Note that the table is obsolete, though. For instance, Turtle supports numeric literals now (but no literal subjects).

[tibotiber]

Hi all, sorry for missing out. Thanks for looking this up and I will look forward to this update.

[RubenVerborgh]

I have tried this with the following code:

var N3 = require('n3');

var store = new N3.Store();
store.addTriple('a', 'b', '"c"');
store.addTriple('"a"', 'b', 'c');
console.log(store.find('"a"', null, null));

This works as expected. Also, nothing in the N3Store code checks for literals.

@tibotiber What problem do you encounter adding triples with a literal as subject/predicate?

[RubenVerborgh]

After a day of fixing, this issue would be the only showstopper for version 0.3.0.
Can you confirm whether a fix is actually necessary?

[tibotiber]

Woaw, I was not paying attention to emails on a good sunday and what a surprise bunch of issue solving I find this morning. Great job! :) I will try to find time later this week to check all of your updates.

On this particular one since it is the showstopper, some more info below, sorry for not posting earlier.
I'm using a personal fork (for triples removal) of N3.js v0.2.7.
I'm executing the following (stream being an inference result from EYE):

var parser = N3.Parser();
parser.parse(stream, function (error, triple, prefixes) {
    if(!error) {
        // add triples to the store                                                                                                                  
        if (triple)
            store.addTriple(triple);
        else
            //done parsing triples                                                                                                                   
            cb(null);
    } else {
        cb(error);
    }
}, function(prefix, uri) {
    // some other stuff
});

and I get the following error:

Error: Expected subject but got literal at line 280.

Below is the content of line 280:

"A1" a xsd:string.

It seems to be coming from N3Parser, in _readSubject().

[RubenVerborgh]

That's right, the current parser is a Turtle parser, not (yet) an N3 parser. As such, parsing a triple with a literal in the subject would violate the specification.

As the name of the library implies, N3.js will parse N3 at some point, but I have to write a parser then with two distinct modes (Turtle / N3).

I will thus close this issue for now and proceed with v0.3.0.

[akuckartz]

@RubenVerborgh If I understand this correctly then this issue is not resolved. I therefore suggest to use GitHub milestones instead of closing the issue.

[RubenVerborgh]

Well, the issue is part of a larger feature to be implemented.
The problem is, if I create an issue “Implement N3 parsing”, that the issue counter will be non-zero; and that makes it hard for me to remember which of my repositories need fixes.
Do you know any way around that?

[RubenVerborgh]

Perhaps I could attach a “future” label to this issue?

[akuckartz]

I see. I think it is important to make it possible to automatically determine all unresolved issues. A "future" label should do that.

[RubenVerborgh]

Fair enough. Here you go 😄

[tibotiber]

Hi! Thanks for the clarification on this matter. No issue with keeping it for later as I have patched it with finer N3 rules. Will look forward to the implementation of that double parser in the future though :).

[RubenVerborgh]

This has been supported for some time now.