Switch to RDF/JS representation #73

iddan · 2018-12-18T13:36:09Z

Currently RDFTerms (Literals, IRIs and prefixed IRIs) are represented as strings.
I suggest to use the RDF/JSON representation for RDF values.
Also, prefixed IRIs should be distinguished from IRIs.

import { Parser } from 'sparqljs';
const parser = new Parser();
parser.parse(`
PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
SELECT *
WHERE {
    ?person foaf:name ?name .
    ?person foaf:mbox ?email .
}
`)

Should return

{
  "queryType": "SELECT",
  "variables": [
    "*"
  ],
  "where": [
    {
      "type": "bgp",
      "triples": [
        {
          "subject": {
              "type": "variable",
              "identifier": "person"
          },
          "predicate": {
              "type": "prefixed-iri",
              "prefix": "foaf",
              "value": "name"
          },
          "object": {
              "type": "variable",
              "identifier": "name"
          }
        },
        {
          "subject": {
              "type": "variable",
              "identifier": "person"
          },
          "predicate": {
              "type": "iri",
              "value": "http://xmlns.com/foaf/0.1/mbox"
          },
          "object": {
              "type": "variable",
              "identifier": "email"
          }
        }
      ]
    }
  ],
  "type": "query",
  "prefixes": {
    "foaf": "http://xmlns.com/foaf/0.1/"
  }
}

We'd be happy to offer a PR

RubenVerborgh · 2018-12-18T13:43:11Z

Thanks for volunteering. I would propose the RDF/JS interface: http://rdf.js.org What you could do is pass in a factory to the parser constructor (RDF/JS has this). That way, you can have your favorite JSON output, and others can have their own. Essentially, the needed changes should just be passing in the factory and calling its methods to create terms and triples. Good plan? If so, I can give you some suggestions on how to get started. Ruben

iddan · 2018-12-18T13:48:31Z

Amazing one! Please do

iddan · 2018-12-18T13:50:40Z

Something I miss in it is an explicit representation for a Prefixed URI. Do you know if it includes it?

RubenVerborgh · 2018-12-18T13:52:00Z

It does not, becaude that is only syntactical, not in RDF terms. But I have a solution if you need it.

iddan · 2018-12-18T15:10:42Z

I think we should use the RDF/JSON as you suggested and additionally define a prefixed URI and variable types. What do you think?

akuckartz · 2018-12-18T18:01:27Z

JSON-LD ?

RubenVerborgh · 2018-12-18T19:51:27Z

I think we should use the RDF/JSON as you suggested and additionally define a prefixed URI and variable types.

RDF/JS does have variables in there already.

It purposely does not have a prefixed URI, because that is not a different term type.
That said, here's my solution for this:

The DataFactory interface has a method NamedNode namedNode(string value)
Call this method with factory.namedNode('http://xmlns.com/foaf/0.1/knows', { prefix: 'foaf', localName: 'knows' })
RDF/JS-compliant implementations ignore the second argument
Your implementation can use the second argument as it pleases

RubenVerborgh · 2018-12-18T19:52:09Z

JSON-LD ?

The main function of the parse tree is to use it within JavaScript, not exchanging it across implementations. For exchange, I'd recommend the SPARQL query itself.

RubenVerborgh · 2018-12-18T19:57:02Z

Proposed plan of implementation (AKA how I would do it, but your opinion might differ):

accept a { factory: … } options object to the SparqlParser constructor
make factory default to the N3.js data factory
in /test/, create an implementation of the factory that returns the current object
- this avoids that you have to change tests themselves, only their setup
- can easily be implemented by adding a wrapper around the N3.js factory: namedNode = value => n3.DataFactory.namedNode(value).id
wire up the tests to use the test factory
- tests should keep on running
replace all code to create terms and triples by calls to N3.js
- tests should keep on running

RubenVerborgh · 2018-12-30T20:03:29Z

FYI Linked to this in the README: 836017e

namedgraph · 2019-01-13T00:18:50Z

How about using SPIN SPARQL syntax as RDF representation? https://www.w3.org/Submission/spin-sparql/

iddan · 2019-01-13T00:59:42Z

Because this is a JavaScript library it makes the most sense to use a spec made for JavaScript representation of RDF. Also, the main goal is to be able to easily distinguish between term types without further string parsing.

iddan · 2019-01-13T01:02:00Z

@RubenVerborgh does the change require changing the JISON syntax file as well?

namedgraph · 2019-01-13T15:12:20Z

You'll still need a vocabulary for the JSON representation. Why invent the bike? Stand on the shoulders of giants, and all that...
You could use JSON-LD to write SPIN syntax -- would that achieve your objective?

RubenVerborgh · 2019-01-13T16:12:00Z

How about using SPIN SPARQL syntax as RDF representation?

We’re not looking for an RDF representation, but rather for a JavaScript in-memory representation.

RubenVerborgh · 2019-01-13T16:13:02Z

does the change require changing the JISON syntax file as well?

Yes, but only to its JavaScript parts that generate terms.

iddan · 2019-01-13T17:14:46Z

I'd need help with that. Unfortunately, I have never written something like BISON or JISON

RubenVerborgh · 2019-01-13T20:33:35Z

It's pretty easy, as all the Jison stuff has been written already and you don't really have to touch it for this. All you need to alter is the JavaScript embedded within the Jison. For example:

      $$ = resolveIRI(expansion + $1.substr(namePos + 1));

will become something like

      var uriString = resolveIRI(expansion + $1.substr(namePos + 1));
      $$ = factory.namedNode(uriString);

namedgraph · 2019-03-04T21:05:06Z

How big of a task would this be? Is it only the s/p/o that need to be changed or more than that?
If someone could summarize that, I could take a crack at it (not promising anything :))

RubenVerborgh · 2019-03-04T21:06:04Z

Just the s/p/o; summary right above 🙂 Thanks for taking a stab at this.

simonvbrae · 2019-07-23T12:34:16Z

@RubenVerborgh
The way it is right now, the array of variables in a JSON representation sometimes contains a string ("*") and sometimes an array of TermTypes. @rubensworks would like to see this changed and has suggested to make it so "variables" is always a list of strings. That way users don't have to check what exactly it contains.
Personally I think that that would be too much work in our codebase for the reward, and it might complicate code in other places like SPARQLAlgebra where elements of the variables array sometimes have to contain other attributes like an expression.

What do you think? Is this worth it? and what solution do you recommend?

RubenVerborgh · 2019-07-23T13:19:55Z

Hmm, interesting case. @rubensworks is there something to be said for a superclass of Term (SparqlTerm?) of which WildcardTerm is an instance?
I’d like to see consistency in our use of Term; not sometimes strings.

rubensworks · 2019-07-23T13:27:01Z

I think if we go down the route of creating a new Term type, we may run into issues with packages downstream, as these will not know how to handle this special Term type.
But it should definitely be possible to do though, but this should be documented in detail then.

Simply making all values of the variables array to be strings would not require special handling and documentation, as it will be immediately clear to users that they are not working with Terms anymore.

In any case, there is no one clean solution I'm afraid, other than changing the RDFJS spec, which would also not be very clean.

RubenVerborgh · 2019-07-23T13:47:12Z

Slight difference perhaps: I wrote superclass of Term. It could still implement all Term methods and properties (mainly equals to false), but would (strictly) not be a Term.

rubensworks · 2019-07-23T13:58:34Z

Sure, we could try that.
Perhaps @joachimvh could share his insights on the usability of the superclass approach within SPARQLAlgebra.js.

namedgraph · 2019-07-23T19:57:17Z

Keep in mind that changes will also propagate to TypeScript bindings:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/sparqljs/index.d.ts

Type structure changes will break code.

RubenVerborgh · 2019-07-23T20:06:48Z

Hopefully TypeScript defs are versioned? Will be a semver major in any case.

namedgraph · 2019-07-23T20:13:55Z

I am not sure actually. They're simply on a Git repo. From this it looks like versioning is not supported: DefinitelyTyped/DefinitelyTyped#7719

Maybe @AlexeyMz could help, he's the author of the typings. Currently they say:

// Type definitions for sparqljs 2.1

AlexeyMz · 2019-07-23T20:21:33Z

@namedgraph DefinitelyTyped covers this situation in the README:

If you intend to continue updating the older version of a library's type declarations, you may create a new subfolder (e.g. /v2/) named for the current (soon to be "old") version, and copy existing files from the current version to it.

https://github.com/DefinitelyTyped/DefinitelyTyped#if-a-library-is-updated-to-a-new-major-version-with-breaking-changes-how-should-i-update-its-type-declaration-package

So we should be fine with moving current typings into types/sparqljs/v2/ and put updated typings for [email protected].

AlexeyMz · 2019-07-23T20:56:40Z

The way it is right now, the array of variables in a JSON representation sometimes contains a string ("*") and sometimes an array of TermTypes. @rubensworks would like to see this changed and has suggested to make it so "variables" is always a list of strings. That way users don't have to check what exactly it contains.

We extensively use Sparql.js in our projects and usually you don't want to treat *-projection the same way as an array of variables (where each one is a term or an expression), e.g. you can't append another term to variables if it's a *. So I think it make sense to treat it separately like in the grammar:

https://www.w3.org/TR/sparql11-query/#rSelectClause

iddan · 2019-07-24T07:35:49Z

This is very true. The tree should reflect the query

joachimvh · 2019-07-24T08:11:08Z

Perhaps @joachimvh could share his insights on the usability of the superclass approach within SPARQLAlgebra.js.

SPARQLAlgebra will need rewriting after this update anyway. But in the conversion I immediately convert '*' to the correct variables so I won't be using much of this new term anyway.

RubenVerborgh · 2019-07-31T12:14:35Z

Released as 3.0.0-beta.0 via #80.

jacoscaz · 2020-06-22T08:41:04Z

Apologies for resurrecting an old issue but it seems to be the most appropriate place for me to point out what follows.

It looks like the typings at https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/sparqljs/index.d.ts have not been updated after the transition to RDF/JS. I double-checked with @rubensworks on gitter.im to make sure I wasn't missing anything and this does seem to be the case.

Has any work ever been put on this?

RubenVerborgh · 2020-06-23T08:00:27Z

@jacoscaz Not yet, tracking in #98

RubenVerborgh changed the title ~~Update SPARQL.js to use RDF/JSON representation for RDFTerm and Variable~~ Switch to RDF/JS representation Dec 30, 2018

RubenVerborgh assigned iddan Dec 30, 2018

RubenVerborgh added the feature request label Dec 30, 2018

namedgraph mentioned this issue Mar 9, 2019

Output RDF/JS terms #80

Merged

RubenVerborgh closed this as completed Nov 6, 2019

RubenVerborgh mentioned this issue Jun 23, 2020

Update typings to RDF/JS #98

Open

Switch to RDF/JS representation #73

Switch to RDF/JS representation #73

Comments

iddan commented Dec 18, 2018 • edited Loading

RubenVerborgh commented Dec 18, 2018 via email

iddan commented Dec 18, 2018

iddan commented Dec 18, 2018

RubenVerborgh commented Dec 18, 2018 via email

iddan commented Dec 18, 2018

akuckartz commented Dec 18, 2018

RubenVerborgh commented Dec 18, 2018

RubenVerborgh commented Dec 18, 2018

RubenVerborgh commented Dec 18, 2018

RubenVerborgh commented Dec 30, 2018

namedgraph commented Jan 13, 2019

iddan commented Jan 13, 2019 • edited Loading

iddan commented Jan 13, 2019

namedgraph commented Jan 13, 2019

RubenVerborgh commented Jan 13, 2019 • edited Loading

RubenVerborgh commented Jan 13, 2019

iddan commented Jan 13, 2019

RubenVerborgh commented Jan 13, 2019

namedgraph commented Mar 4, 2019

RubenVerborgh commented Mar 4, 2019

simonvbrae commented Jul 23, 2019 • edited Loading

RubenVerborgh commented Jul 23, 2019

rubensworks commented Jul 23, 2019

RubenVerborgh commented Jul 23, 2019

rubensworks commented Jul 23, 2019

namedgraph commented Jul 23, 2019

RubenVerborgh commented Jul 23, 2019 via email

namedgraph commented Jul 23, 2019 • edited Loading

AlexeyMz commented Jul 23, 2019 • edited Loading

AlexeyMz commented Jul 23, 2019

iddan commented Jul 24, 2019

joachimvh commented Jul 24, 2019

RubenVerborgh commented Jul 31, 2019

jacoscaz commented Jun 22, 2020 • edited Loading

RubenVerborgh commented Jun 23, 2020

iddan commented Dec 18, 2018 •

edited

Loading

iddan commented Jan 13, 2019 •

edited

Loading

RubenVerborgh commented Jan 13, 2019 •

edited

Loading

simonvbrae commented Jul 23, 2019 •

edited

Loading

namedgraph commented Jul 23, 2019 •

edited

Loading

AlexeyMz commented Jul 23, 2019 •

edited

Loading

jacoscaz commented Jun 22, 2020 •

edited

Loading