goofballlogic / ld-query Goto Github PK

If you pass in {} as the context, you get an error:

TypeError: expand is not a function
    at extractStep (/home/ubuntu/workspace/node_modules/ld-query/src/ld-query.js:284:29)
    at getSteps (/home/ubuntu/workspace/node_modules/ld-query/src/ld-query.js:296:25)
    at select (/home/ubuntu/workspace/node_modules/ld-query/src/ld-query.js:326:21)
    at QueryNode.query (/home/ubuntu/workspace/node_modules/ld-query/src/ld-query.js:351:25)

Some examples of using the library:

1. Client-side javascript
2. node.js

if I query a document

[ {
   "http://example.org#name" : [ { "@value" : "Gwyneth" } ],
   "http://example.org#age" : [ { "@value" : 0 } ]
} ]

using

const age = doc.query( "ex:age @value" );

it returns a null, when I expect a 0

I've noticed that attributes can be arrays e.g.

"@type": [
    "http://www.example.org#deleteOperation",
    "http://www.w3.org/ns/hydra/core#DeleteResourceOperation"
]

The current matching does not handle this.

The document I'm querying is Example 2 from http://schema.org/Book.
Here's a relevant snippet:

{
  "@context": "http://schema.org",
  "@graph": [
    {
      "@id": "#author",
      "@type": "Person",
      "birthDate": "1892",
      "deathDate": "1973",
      "name": "Tolkien, J. R. R. (John Ronald Reuel)",
      "sameAs": "http://viaf.org/viaf/95218067"
    }]
}

Here is my query:

const doc = LD({
    "@vocab": "http://schema.org/",
})(expanded)
expect(doc.query("[name=Tolkien, J. R. R. (John Ronald Reuel)]")).to.exist

This returns null, whereas I expect it to return the author's node.

Am I misunderstanding how the [@attribute=value] code is supposed to work? I'd like to be able to query on matching values within the document, not just on document structure. Is this supported?

Internally, I see your extractStep function is calling expand on step.value because it doesn't match the nonExpandableValuePropNamePattern. We end up with the value http://schema.org/Return of the King.

If I comment out the call to expand the query still fails to match, so there's something else going on as well.

For the same document in the README.md, how would I go about mapping the entries under favouriteReads to my own document model?

At the moment I would have to do

var favs = doc.query("ex:favouriteReads"); // query for favouriteReads
if ( favs ) {  // check it isn't null
  model = favs.json() // get the array
    .map( x => ldQuery( x ) ) // map each aray entry to a new query object
    .map( x=> ( { // query again to create my own document model
      author: x.query( "so:author @value" ),
      title: x.query( "so:name @value" )
    } ) );
}

Is there a shorter way to do this?
I guess one way could be that if you use 'queryAll' against a path ("ex:favouriteReads") that points to an array that you get each entry of the array as a QueryNode? Or might that lead to confusing use cases?

The other option would be wildcards e.g.

model = doc.queryAll("ex:favouriteReads > *") // query for all children of favouriteReads
// since queryAll returns either an empty array or an array of queryNodes
// you can skip the safety check and go directly to mapping
    .map( x=> ( { 
      author: x.query( "so:author @value" ),
      title: x.query( "so:name @value" )
    } ) );

What do you think?

We aim to have as many analogies between our selectors and the CSS level 3 selectors as possible. Define which selectors we provide along with a mapping to the CSS equivalent.

@value returns literal values but @id and @Index do not.

The README.md mentions two constructor patterns

var context = LD( { ... etc. } );
var doc = context( data );

or

var doc = LD( data, { ... context ... } );

only the latter actually works. The former gives a 'Cannot convert undefined or null to object' error

There are features that demonstrate the use of the child combinators, but the README file should be updated to show some too. Also the package.json version needs updated for a new version on npm

Given a document that includes

[
  {
    ...,
    "http://example.org#annotations": [
      {
        "@type": [
          "https://www.w3.org/TR/annotation-model/Annotation"
        ],
        "https://www.w3.org/TR/annotation-model/body": [
          {
            ...,
            "http://example.org#identifier": [
              {
                "@value": "annotation1_identifier"
              }
            ]
          }
        ],
      },
    ],
    "http://example.org#identifier": [
      {
        "@value": "12345"
      }
    ],
  }
]

what should we expect query( "ex:identifier" ) to return? The "annotation1_identifier" or "12345"? At the moment it is "annotation1_identifier", the first entry that matches the query.

If this was html e.g.

<div class="b">
  <div class="b">
    <div class="a">test1</div>
  </div>
</div>
<div class="a">test2</div>

then document.querySelector(".a").innerHTML returns "test1", so that matches the functionality of the ld-query 'query' method

To get 'test2' in the html we'd need to use document.querySelector( "body > .a" )

Does ld-query need changed to find the 'simplest' match for a path? Or does it need to include additional operator types like '>'? Or can the 'expand' method that it uses internally be externalised, so that developers can process json manually (though that's a bit of a fudge)?

Change behaviour to match analogous https://www.w3.org/TR/selectors-api2/

In order to more clearly document how the library tries to follow https://www.w3.org/TR/selectors-api2/ we should switch over to cucumber.js

At the bottom of your Examples you list an example that has an attribute clause:
doc.query("so:favouriteReads[@Index=pynchon_gp] so:name @value") // "Gravity's Rainbow"

There does not appear to be any implementation for this though.

(also, as an aside, your 'main' entry in package.json is pointing to dist/ld-query.js, which does not exist)

When searching in a document for a node with arbitrary identity (e.g. [@id=http://xyz.com]) this will only match if the identified node is at the top of the queryied JSON.

Currently, if you query for @id, @value or @Index, you get the literal value back, rather than a QueryNode(s). Currently querying for @type returns QueryNode - shouldn't it also return the value instead? If there's more than one @type, an array of the literal values could be returned.

ex:node [@index=1234]
( select the descendent of ex:node with an @Index of 1234 )

is incorrectly interpreted as:

ex:node[@index=1234]
( select the ex:node with an @Index of 1234 )

If we specify @vocab as part of the json-ld context, querying for bare property names should then be interpreted as belonging to the @vocab.

e.g. if the context is

{
    "@vocab": "http://www.example.org#"
}

then a query for "name @value" should be interpreted as targetting:

{
    "http://www.example.org#name": [ { "@value": "gabrisha" } ]
}