Coder Social home page Coder Social logo

ld-query's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

ld-query's Issues

Empty context causes error

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)

Add examples

Some examples of using the library:

  1. Client-side javascript
  2. node.js

Querying for a @value of 0 returns a null

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

Attribute matching doesn't handle arrays

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.

[@attribute=value] does not appear to work with regular strings as value

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.

Simplifying processing of array elements

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?

Documentation mentions a constructor pattern that doesn't work

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

Precedence of result from 'query'

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)?

Should @type be "final"

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.

Accept @vocab as part of the context

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" } ]
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.