It seems --dbg does not work?

$ jsonld --dbg in.json 
/Users/user/.gem/ruby/2.4.0/gems/json-ld-2.1.3/bin/jsonld:133:in `block in <top (required)>': undefined method `debug=' for JSON::LD:Module (NoMethodError)
	from /usr/local/Cellar/ruby/2.4.1_1/lib/ruby/2.4.0/getoptlong.rb:605:in `block in each'
	from /usr/local/Cellar/ruby/2.4.1_1/lib/ruby/2.4.0/getoptlong.rb:602:in `loop'
	from /usr/local/Cellar/ruby/2.4.1_1/lib/ruby/2.4.0/getoptlong.rb:602:in `each'
	from /Users/user/.gem/ruby/2.4.0/gems/json-ld-2.1.3/bin/jsonld:131:in `<top (required)>'
	from /Users/user/.gem/ruby/2.4.0/bin/jsonld:22:in `load'
	from /Users/user/.gem/ruby/2.4.0/bin/jsonld:22:in `<main>'

The -h command-line option might perhaps do something more useful than the current output:

$ jsonld -h
/usr/bin/jsonld: invalid option -- h
/usr/lib/ruby/2.0.0/getoptlong.rb:394:in `set_error': invalid option -- h (GetoptLong::InvalidOption)
    from /usr/lib/ruby/2.0.0/getoptlong.rb:571:in `get'
    from /usr/lib/ruby/2.0.0/getoptlong.rb:602:in `block in each'
    from /usr/lib/ruby/2.0.0/getoptlong.rb:601:in `loop'
    from /usr/lib/ruby/2.0.0/getoptlong.rb:601:in `each'
    from bin/jsonld:122:in `<top (required)>'
    from /usr/bin/jsonld:23:in `load'
    from /usr/bin/jsonld:23:in `<main>'

Consider:

require 'rubygems'
require 'json/ld'

input = JSON.parse %([{
    "http://xmlns.com/foaf/0.1/name": ["Manu Sporny"],
    "http://xmlns.com/foaf/0.1/homepage": [{"@id": "http://manu.sporny.org/"}],
    "http://xmlns.com/foaf/0.1/avatar": [{"@id": "http://twitter.com/account/profile_image/manusporny"}]
}])

context = JSON.parse('{
  "@context": [
"http://assets.lawly.eu/ld/context.jsonld",
{
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {"@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id"},
    "avatar": {"@id": "http://xmlns.com/foaf/0.1/avatar", "@type": "@id"}
  }
]
}')['@context']

puts JSON::LD::API.compact(input, context)

Result:

{"@context"=>"http://assets.lawly.eu/ld/context.jsonld", "avatar"=>"http://twitter.com/account/profile_image/manusporny", "homepage"=>"http://manu.sporny.org/", "name"=>"Manu Sporny"}

I would expect the name, homepage and avatar mappings to show up in the context.

Trying to parse https://raw.githubusercontent.com/taverna/taverna-prov/master/example/helloanyone.bundle/.ro/manifest.json (either by file or URL) fails with

JSON::LD::JsonLdError::RecursiveContextInclusion: recursive context inclusion: https://w3id.org/bundle/context

This seems to be because of:

"@context" : [ "https://w3id.org/bundle/context" ],

If I modify the above @context to use the resolved URI after redirection from w3id.

http://wf4ever.github.io/ro/bundle/context.json

then it parses. Note that the https variant (Which I probably should redirect to):

https://wf4ever.github.io/ro/bundle/context.json

then I instead get an error:

JSON::LD::JsonLdError::LoadingDocumentFailed: loading document failed: <https://wf4ever.github.io/ro/bundle/context.json>: Bad Request(400)

.. which is odd given that https://wf4ever.github.io/ro/bundle/context.json does not give a 400 error if tested with curl, wget or Chrome.

IRB transcript:

stain@biggie-mint ~/2 $ ruby -v
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]

stain@biggie-mint ~/2 $ gem list

*** LOCAL GEMS ***

bigdecimal (1.2.4)
bundler (1.6.2)
bundler-unload (1.0.2)
executable-hooks (1.3.1)
gem-wrappers (1.2.4)
io-console (0.4.2)
json (1.8.1)
json-ld (1.1.5)
minitest (4.7.5)
psych (2.0.3)
rake (10.1.0)
rdf (1.1.4.1)
rdoc (4.1.0)
rubygems-bundler (1.4.3)
rvm (1.11.3.9)
test-unit (2.1.1.0)

2.1.1 :009 >   require 'openssl'
 => false 
2.1.1 :010 > require 'json/ld'
 => false 
2.1.1 :011 > RDF::Graph.load("https://raw.githubusercontent.com/taverna/taverna-prov/master/example/helloanyone.bundle/.ro/manifest.json", :format => :jsonld, :base => "app://d231bc00-909f-4dfd-a0a9-b4b5ea23ed21/")
JSON::LD::JsonLdError::RecursiveContextInclusion: recursive context inclusion: https://w3id.org/bundle/context
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:250:in `block (2 levels) in parse'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/utils.rb:136:in `depth'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:222:in `block in parse'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:221:in `each'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:221:in `parse'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:291:in `block (2 levels) in parse'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/utils.rb:136:in `depth'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:222:in `block in parse'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:221:in `each'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/context.rb:221:in `parse'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/expand.rb:41:in `expand'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/api.rb:135:in `block in expand'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/api.rb:110:in `call'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/api.rb:110:in `initialize'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/api.rb:134:in `new'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/json-ld-1.1.5/lib/json/ld/api.rb:134:in `expand'
... 15 levels...
    from /home/stain/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/net/http.rb:1405:in `catch'
    from /home/stain/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/net/http.rb:1405:in `transport_request'
    from /home/stain/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/net/http.rb:1378:in `request'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/util/file.rb:65:in `block in open_file'
    from /home/stain/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/net/http.rb:853:in `start'
    from /home/stain/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/net/http.rb:583:in `start'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/util/file.rb:59:in `open_file'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/reader.rb:136:in `open'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/mixin/mutable.rb:43:in `load'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/model/graph.rb:81:in `block in load'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/model/graph.rb:131:in `call'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/model/graph.rb:131:in `initialize'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/model/graph.rb:80:in `new'
    from /home/stain/.rvm/gems/ruby-2.1.1@jsonld/gems/rdf-1.1.4.1/lib/rdf/model/graph.rb:80:in `load'
    from (irb):11
    from /home/stain/.rvm/rubies/ruby-2.1.1/bin/irb:11:in `<main>'2.1.1 :012 > 

When I try and frame a document, I'm getting a blank graph returned.

require 'linkeddata'

unframed_json = JSON.parse '[
  {
    "@id": "http://vocab.getty.edu/ulan/500115403",
    "http://xmlns.com/foaf/0.1/focus": [
      {
        "@id": "http://vocab.getty.edu/ulan/500115403-agent"
      }
    ],
    "http://www.w3.org/2004/02/skos/core#prefLabel": [
      {
        "@value": "Couture, Thomas"
      }
    ],
    "http://www.w3.org/2004/02/skos/core#inScheme": [
      {
        "@id": "http://vocab.getty.edu/ulan/"
      }
    ],
    "http://schema.org/url": [
      {
        "@id": "http://www.getty.edu/vow/ULANFullDisplay?find=&role=&nation=&subjectid=500115403"
      }
    ]
  }
]'

frame = JSON.parse '{
  "@explicit": true,
  "@context": {
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "schema": "http://schema.org/",
    "label": "skos:prefLabel",
    "id": "@id",
    "source": {
      "@id": "skos:inScheme",
      "@type": "@id"
    },
    "agent": {
      "@id": "foaf:focus",
      "@type": "@id"
    },
    "website": {
      "@id": "schema:url",
      "@type": "@id"
    }
  },
  "label": {},
  "id": {},
  "source": {},
  "agent": {},
  "website": {}
}'

puts JSON::LD::API.frame(unframed_json, frame)

returns

{
 "@context"=>{
  "skos"=>"http://www.w3.org/2004/02/skos/core#", 
  "foaf"=>"http://xmlns.com/foaf/0.1/", 
  "schema"=>"http://schema.org/", 
  "label"=>"skos:prefLabel", 
  "id"=>"@id",
   "source"=>{"@id"=>"skos:inScheme", "@type"=>"@id"}, 
   "agent"=>{"@id"=>"foaf:focus", "@type"=>"@id"}, 
   "website"=>{"@id"=>"schema:url", "@type"=>"@id"}
 }, 
 "@graph"=>[]
}

But when I put the same JSON into the JSON-LD Playground, I get the values I expect:

permalink to Playground

very very small issue in readme.rdoc:

JSON::LD.fromRDF doesn't work, JSON::LD::API.fromRDF is the right call.. also for .frame function.

I saved example 15 from http://www.w3.org/2007/02/turtle/primer/#example15 as students.ttl, and issued the following command:

$ rdf serialize --input-format turtle students.ttl --output-format jsonld
{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "s": "http://example.org/students/vocab#"
  },
  "@id": "http://example.org/courses/6.001",
  "http://example.org/students/vocab#students": {
    "@list": [
      {
        "@id": "http://example.org/students/Amy"
      },
      {
        "@id": "http://example.org/students/Mohamed"
      }
    ]
  }
}

Johann is missing from the output. This doesn't happen for the other output formats (n3, triples, rdfa). and it seems to always be missing ALL elements except the first two.

I have RSpec tests that looks for Product data and returns the first found Product on a page (and tries to merge together solutions to get an Array of image for that Product). This was working on 3.1.8, but after updating to 3.1.9 it seems to fail as the solutions have started coming back with no clear order.

Here's some example HTML:

<html>
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "The first Product",
    "sku": "12345",
    "url": "https://site.com/first-product",
    "image": "https://site.com/first-image.jpg",
    "offers": {
      "@type": "Offer",
      "price": "10",
      "priceCurrency": "CNY",
      "offeredBy": "Bob"
    }
  }
</script>
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "A second product",
    "sku": "67890",
    "url": "https://site.com/second-product",
    "image": [
      "https://site.com/second-image.jpg",
      "https://site.com/third-image.jpg"
    ],
    "offers": {
      "@type": "Offer",
      "price": "100",
      "priceCurrency": "GBP",
      "offeredBy": "Alice"
    }
  }
</script>
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "The first Product",
    "sku": "12345",
    "url": "https://site.com/first-product",
    "image": [
      "https://site.com/first-image.jpg",
      "https://site.com/fourth-image.jpg"
    ],
    "offers": {
      "@type": "Offer",
      "price": "10",
      "priceCurrency": "CNY",
      "offeredBy": "Bob"
    }
  }
</script>
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "The first Product",
    "sku": "12345",
    "url": "https://site.com/first-product",
    "offers": {
      "@type": "Offer",
      "price": "10",
      "priceCurrency": "CNY",
      "offeredBy": "Bob"
    }
  }
</script>
</html>

One of the tests expects to find a URL of https://site.com/first-product, but now fails half the time, returning https://site.com/second-product instead.

Is this a known issue, and if so, is there a way to ensure that returned solutions come back deterministically (ie in the order they're found in the HTML)?

It'd probably be a good idea to tighten the RDF.rb version dependency a bit on the JSON::LD 1.1.x branch, as right now it will happily pull in RDF.rb 1.99.x on a machine that doesn't already have it installed:

$ sudo gem install json-ld -v 1.1.11
Fetching: link_header-0.0.8.gem (100%)
Fetching: rdf-1.99.0.gem (100%)
Fetching: multi_json-1.11.2.gem (100%)
Fetching: json-ld-1.1.11.gem (100%)
Successfully installed link_header-0.0.8
Successfully installed rdf-1.99.0
Successfully installed multi_json-1.11.2
Successfully installed json-ld-1.1.11
4 gems installed

This means that in normal use, users will see tons of deprecation notices for what ought to be a production release of the JSON::LD library and CLI utility.

Hi!
Is it possible to normalize json with this gem?
Thank you!

https://bibdata.princeton.edu/bibliographic/4609321/jsonld

Running this through the reader doesn't parse anything from the first context, only the second. There are callouts in the spec for supporting multiple contexts, and http://rdf-translator.appspot.com/ seems to work how I'd expect.

Trying to convert the file at

http://raimond.me.uk/resources/jsonld-issue-test.ttl

from Turtle to JSON-LD using the command line

rdf serialize --output-format jsonld --input-format turtle http://raimond.me.uk/resources/jsonld-issue-test.ttl

Gives the following exception:

.gem/ruby/1.9.1/gems/json-ld-1.0.5/lib/json/ld/context.rb:514:in `[]=': can't add a new key into hash during iteration (RuntimeError)

Looking at the code, it seems to be marked as deprecated, so not sure why it is calling it. It is looking like term_definitions is being modified whilst being looped through.

Reader Class JSON::LD::Reader

#<JSON::LD::Reader:0x000055eb154712c8 @options={:encoding=>#<Encoding:UTF-8>, :validate=>false, :canonicalize=>false, :intern=>true, :prefixes=>{}, :base_uri=>nil}, @input=#<StringIO:0x000055eb15470b98>, @doc=#<StringIO:0x000055eb154707d8>>
FATAL Failed to parse input document: loading remote context failed: https://schema.org: undefined method `inner_html' for nil:NilClass: Called from /usr/local/bundle/gems/json-ld-3.1.0/lib/json/ld/reader.rb:90

If I .gsub the content of the JSON LD to replace schema.org with the URL of the context file, it no longer chokes on the message.

if formattype.to_s =~ /JSON\:\:LD\:\:Format/
         body = body.gsub(/https?\:\/\/schema.org\/?/, "https://schema.org/docs/jsonldcontext.json")
        $stderr.puts "new body\n\n#{body}"
end

This workaround is fine, but I'm curious what the root cause of the problem is...??

There are currently no examples on how to set a persistent option on the jsonld API to use a custom document loader. The goal is to cache specific jsonld context documents using a custom document loader. (I'm running into pesky intermittent problems using rack-cache with rest-client and actually rack-cache is overkill for the purpose of only caching a few jsonld context docs.)

I'm looking for an example similar to this python code from @azaroth42 at https://github.com/azaroth42/anno_context_switcher/blob/master/context_switcher.py#L6-L25.

I'm using SPARQL to query some JSON-LD, but for some reason the itemListElement of an ItemList is not being returned. It looks to be related to the @id property being present on the Product
Here's a query to match everything:

PREFIX rsp: <http://rubygems.org/gems/sparql#>
      PREFIX s: <http://schema.org/>

      SELECT *
      WHERE {
        ?s ?p ?o
      }

Here's my JSON-LD

  {
    "@context": "http://schema.org",
    "@type": "ItemList",
    "name": null,
    "description": null,
    "numberOfItems": 4,
    "itemListOrder": "Relevance",
    "url": "https://www.example.com",
    "itemListElement": [
      {
        "@type": "Product",
        "@id": "123456",
        "name": "Product Name",
        "sku": "product-name",
        "url": "https://www.example.com/product",
        "image": "https://www.example.com/image.jpg",
        "position": 1,
        "potentialAction": {
          "@type": "Action",
          "name": "Add to cart"
        }
      }
    ]
  }

Here's the list of solutions:

{:s=>#<RDF::Node:0x2afcccbc4960(_:b1)>, :p=>#<RDF::Vocabulary::Term:0x2afccb3fb658 ID:http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, :o=>#<RDF::URI:0x2afcccbc4938 URI:http://schema.org/Action>}
{:s=>#<RDF::Node:0x2afcccbc4960(_:b1)>, :p=>#<RDF::URI:0x2afcccbc4604 URI:http://schema.org/name>, :o=>#<RDF::Literal:0x2afcccbc458c("Add to cart")>}
{:s=>#<RDF::Node:0x2afcccbb2db4(_:b0)>, :p=>#<RDF::Vocabulary::Term:0x2afccb3fb658 ID:http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, :o=>#<RDF::URI:0x2afcccbb2d64 URI:http://schema.org/ItemList>}
{:s=>#<RDF::Node:0x2afcccbb2db4(_:b0)>, :p=>#<RDF::URI:0x2afcccbb292c URI:http://schema.org/numberOfItems>, :o=>#<RDF::Literal::Integer:0x2afcccbb2814("4"^^<http://www.w3.org/2001/XMLSchema#integer>)>}
{:s=>#<RDF::Node:0x2afcccbb2db4(_:b0)>, :p=>#<RDF::URI:0x2afcccbb23c8 URI:http://schema.org/itemListOrder>, :o=>#<RDF::Literal:0x2afcccbb2350("Relevance")>}
{:s=>#<RDF::Node:0x2afcccbb2db4(_:b0)>, :p=>#<RDF::URI:0x2afcccbc5f2c URI:http://schema.org/url>, :o=>#<RDF::URI:0x2afcccbc5eb4 URI:https://www.example.com>}

Hi, I was testing the JSON-LD 1.1 ruby client. And I found if the value of a json_doc is an integer, the @base parameter wouldn't work.
e.g. (the value of "_id" is integer here)

{
"@context": {
   "@version": 1.1,
   "_id": {
       "@type": "@id",
       "@id": "http://www.w3.org/2004/02/skos/core#exactMatch",
       "@context": {
             "@base": "http://identifiers.org/hgnc.symbol/"
        }
   }
},
"@id": "http://mygene.info/1017",
"_id": 1017
}

This wouldn't convert the value of "_id", the compacted output is like follows:

{
  "@id": "http://mygene.info/1017",
  "http://www.w3.org/2004/02/skos/core#exactMatch": {
    "@id": "1017"
  }
}

However, if I change the value of "_id" into "1017", it works.
e.g.

{
"@context": {
   "@version": 1.1,
   "_id": {
       "@type": "@id",
       "@id": "http://www.w3.org/2004/02/skos/core#exactMatch",
       "@context": {
             "@base": "http://identifiers.org/hgnc.symbol/"
        }
   }
},
"@id": "http://mygene.info/1017",
"_id": "1017"
}

Here, I get what I want
e.g.

{
  "@id": "http://mygene.info/1017",
  "http://www.w3.org/2004/02/skos/core#exactMatch": {
    "@id": "http://identifiers.org/hgnc.symbol/1017"
  }
}

I'm wondering is this a bug in the client?

Thanks!

Where can I find a complete tutorial or example for newbie (step by step) who explain how can I use your gem ?

Thanks

An example is this LDP Container with ~6,000 member objects. The benchmark included in the gist shows a total time of 32.45 seconds to parse the document via RDF::Graph#load. Using RDF::Reader#open is similarly slow. Based on behavior I've seen with similarly sized documents, I'm expecting results closer to the 1 second range.

I haven't tracked down a specific reason for this, yet. One clue might be that this graph also seems unusually slow to parse as NTriples and Turtle in 1.99.1, but not in 2.0.0.beta1. My suspicion is that it has to do with the very high cardinality of the <> ldp:contains ?o pattern.

Thanks to @tpendragon for raising this issue.

When given a hash with an embedded @context, it can end up removing @context from the nested hash.

This seems to be because of

Hi Gregg!

I'm a bit stuck. I suspect this isn't a "bug", just a configuration problem, but I don't know how to solve it.

I have a Ruby script running in Apache that uses JSON::LD::Reader. Everything is fine until I attempt to pull things out of the graph, at which point it throws a "certification error". As I understand it, it validates the @context nodes, which is where I have a problem. http://schema.org is redirected to https://schema.org, and this then fails WHEN RUNNING IN THE SERVER with the error: FATAL Failed to parse input document: loading remote context failed: http://schema.org/: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate): Called from /home/mark_moby_wilkinson/.rvm/gems/ruby-2.5.1/gems/json-ld-3.0.2/lib/json/ld/reader.rb:70

If I run it in a terminal window, it has no problem, so I assume that in my own user environment the libraries can see/provide whatever certificates they need. Inside of Apache, apparently they cannot. I'm not sure exactly what they are looking for (my Apache is configured for https, if that matters).

Can you suggest a place to begin the debugging?

Thank you!

Mark

Using "@container" : "@type" when Framing JSON-LD fails when @type is missing.

Test

Graph

{
  "@context": {
    "@vocab": "http://schema.org/"
  },
  "@type": "Event",
  "location": {
    "@id": "http://kg.artsdata.ca/resource/K11-200"
  }
}

Frame

{
  "@context": {
    "@vocab": "http://schema.org/",
    "location": {
      "@type": "@id",
      "@container": "@type"
    }
  },
  "@type": "Event"
}

Expected behaviour

"@none" when there is no @type.

Result from JSON-LD Playground

{
  "@context": {
    "@vocab": "http://schema.org/",
    "location": {
      "@type": "@id",
      "@container": "@type"
    }
  },
  "@type": "Event",
  "location": {
    "@none": "http://kg.artsdata.ca/resource/K11-200"
  }
}

Current behaviour

NoMethodError: undefined method `keys' for "http://kg.artsdata.ca/resource/K11-200":String
if compacted_item.keys.length == 1 && expanded_item.keys.include?('@id')

I see the ruby JSON implementation is used to read the input.

Would it be desired to provide a soft dependency (i.e. not declared in gemspec) on the multi_json gem? This would allow users to supply a more efficient JSON parser for their ruby engine. On MRI that is likely Oj, on JRuby that is likely jrjackson.

The required work is pretty minimal:

• Test for multi_json dependency on LOAD_PATH.
• If present, parse JSON-LD with MultiJson.load.
• If not, fall back to JSON module.

To create a context from an RDFS/OWL definition using the script/gen_context script several parameters are mandatory required, but no example is documented.

Attempted to do with the ontology https://d-nb.info/standards/elementset/gnd.rdf, but got the following error:

$ ruby gen_context.rb --body --initial gnd_20221010.rdf --language en --output gnd_context --prefix "https://d-nb.info/standards/elementset" --vocab "https://d-nb.info/standards/vocab/gnd"

        from /home/rails5/.rbenv/versions/3.2.2/lib/ruby/3.2.0/json/common.rb:216:in `parse'
        from gen_context.rb:69:in `block in <main>'
        from /home/rails5/.rbenv/versions/3.2.2/lib/ruby/3.2.0/getoptlong.rb:863:in `block in each'
        from /home/rails5/.rbenv/versions/3.2.2/lib/ruby/3.2.0/getoptlong.rb:860:in `loop'
        from /home/rails5/.rbenv/versions/3.2.2/lib/ruby/3.2.0/getoptlong.rb:860:in `each'
        from gen_context.rb:66:in `<main>'

What am I doing wrong here?

I've installed the latest version of this gem and run it over an HTML, but using JSON::LD::Reader.new takes over a minute to parse the input. I've set logging to false and skip_registry to true (based on other issues that have been closed here) but they don't make any difference to the time it takes to parse the file. By comparison, scanning the same HTML for Microdata takes a fraction of a second.

Am I missing something obvious?

JSON::LD::API.toRDF doesn't like the use of blank nodes in the object position. Since it works well using other RDF serializers (rdf/ntriples), I suppose that an issue.

So the following test should pass :

require 'json/ld'
require 'rspec'

describe 'JSON::LD::API' do
  describe '.toRDF' do
    context 'when some objects are blank nodes' do

      let(:repository) do
        repository = RDF::Repository.new
        repository << RDF::Statement.new(RDF::URI.new('http://resource.com/subject'), RDF.type, RDF::Node.new)
      end

      let (:json_input) { JSON.parse(repository.dump(:jsonld)) }

      it 'should be valid' do
        JSON::LD::API.toRDF(json_input).should be_kind_of JSON::LD::API
      end

    end
  end
end

I tried to run the following example from the JSON-LD gem Readme :

input = JSON.parse %({
  "@context": {
    "":       "http://manu.sporny.org/",
    "foaf":   "http://xmlns.com/foaf/0.1/"
  },
  "@id":       "http://example.org/people#joebob",
  "@type":          "foaf:Person",
  "foaf:name":      "Joe Bob",
  "foaf:nick":      { "@list": [ "joe", "bob", "jaybe" ] }
})

graph = RDF::Graph.new << JSON::LD::API.toRDF(input)

The last line raises the following error :

NoMethodError: undefined method `to_a' for false:FalseClass
    from /var/lib/gems/1.9.1/gems/rdf-1.0.8/lib/rdf/model/statement.rb:203:in `=='
    from /var/lib/gems/1.9.1/gems/rdf-1.0.8/lib/rdf/model/statement.rb:31:in `from'
    from /var/lib/gems/1.9.1/gems/rdf-1.0.8/lib/rdf/mixin/writable.rb:39:in `<<'
    from /var/lib/gems/1.9.1/gems/rdf-1.0.8/lib/rdf/mixin/mutable.rb:68:in `<<'

JSON::LD::API.toRDF returns an Array, but << method in RDF::Writable module doesn't support Arrays, so it is interpreted like a Statement, and therefore it crashes.

The following example works :

repository = RDF::Repository.new
JSON::LD::API.toRDF(input).each { |s| repository << s }

Is there any DSL to avoid to loop explicity ?

Before working on a PR on this project, I tried to run the test suite to have confidence that my changes won't be regressing anything. I noticed that several examples do not pass anymore, often for trivial reasons like expecting "http://json-ld.org/test-suite/..." and getting "https://json-ld.org/test-suite/..." as shown below.

Would it be possible to update the specs so that they pass?

Here is what I did:

git clone https://github.com/ruby-rdf/json-ld.git
git checkout 2.1.5
edit Gemfile to add `gem "rake"` in the development group
bundle install --path .bundle
bundle exec rake spec

The spec take a long time, and many fail with errors like this one:

       Expected: [
         {
           "@id": "http://example.com/queen",
           "http://example.com/vocab/label": [
             {
               "@value": "The Queen"
             }
           ],
           "http://example.com/vocab/index": [
             {
               "@value": "No"
             },
             {
               "@value": "indexes"
             },
             {
               "@id": "http://json-ld.org/test-suite/tests/asTheValueIsntAnObject"
             }
           ]
         }
       ]
       Actual  : [
         {
           "@id": "http://example.com/queen",
           "http://example.com/vocab/index": [
             {
               "@value": "No"
             },
             {
               "@value": "indexes"
             },
             {
               "@id": "https://json-ld.org/test-suite/tests/asTheValueIsntAnObject"
             }
           ],
           "http://example.com/vocab/label": [
             {
               "@value": "The Queen"
             }
           ]
         }
       ]

On the whole test suite, I have like 35 failed tests as of 2017-09-22.

When using Annotation Objects in a JSON-LD-star document, and then using JSON-LD Framing, I am losing the @Annotate node.

Does JSON::LD::API.frame need to have the setting rdfstar: true ?

 input =  JSON.parse %({
      "@context": {
        "@base":"http://www.artsdata.ca/resource/",
        "@vocab":"http://www.artsdata.ca/resource/"
      },
      "@graph": [
        {
          "@id": "TheShow",
          "@type": "Performance",
          "performer": {
            "@id": "John",
            "@annotation": {
                "certainty": 1
            }
          }
        },
        {
          "@id": "John",
          "@type": "Person",
          "name" : "John Smith"
        }
      ]
    })

frame = JSON.parse %({
      "@context": {
        "@vocab": "http://ontology.artsdata.ca/"
       },
       "@type": "Performance"
    })

JSON::LD::API.frame(input, frame)

The above example results in the loss of the @Annotate node as shown below:

{
  "@context"=>{
     "@base"=>"http://www.artsdata.ca/resource/", 
     "@vocab"=>"http://www.artsdata.ca/resource/"
  }, 
  "@id"=>"TheShow", 
  "@type"=>"Performance", 
  "performer"=>{"@id"=>"John", "@type"=>"Person", "name"=>"John Smith"}
}

Match on other values as well.

Principle Classes should be Principal Classes

The fix done some time ago has issues which were masked likely due to test caching issues.

See discussion in json-ld/json-ld.org#357

This issue is the same as digitalbazaar/jsonld.js#435:

The result compacting the IRI http://localhost/@special against base http://localhost/ is @special, which looks like a keyword. The consequence is that the resulted compact JSON-LD does not expand back to the original.

A workaround would be to compact it to ./@special instead.

Hello,

I have been making a website that lists the available Arduino libraries:
http://www.arduinolibraries.info/

I recently added schema.org structured data in the form of JSON-LD, which is embedded in page, and also available as a JSON document:
http://www.arduinolibraries.info/libraries/ether-sia
http://www.arduinolibraries.info/libraries/ether-sia.json

For fun I thought I would also generate Turtle, from the JSON-LD. But have found it to be surprisingly slow - several seconds, for a very small number of triples.

Code:
njh/arduino-libraries@24e8f9d#diff-55ef48a181f10f92f33bc40126b4378cR38

Do you have any idea why?
Is there a more efficient way of doing it?

The whole site used to generated in around 2 seconds, now it takes longer than that for one document.

nick.

It wasn't clear how to use the --format command-line option. I would have expected one of the following formulations to work, but they both resulted in an unhelpful stack trace:

jsonld --format=nt example.jsonld
jsonld --format=application/n-triples example.jsonld

However, I eventually figured out that the following formulation does indeed work:

jsonld --format=ntriples example.jsonld

Perhaps the --help text for --format might be enhanced to mention (e.g., "ntriples") or the like?

I'm looking at generating JSON-LD from an API based off a SQL-based db, not a graph db. Its not clear to me whether using RDF at all would be appropriate. If RDF is not used, is this library useful (as it seems to be just for reading/writing with RDF)? Or would I be better exploring other ways to generate JSON-LD?

I'm learning as I go here, so any suggestions would be much appreciated :)

When using the linkeddata gem (v. 2.2.0), when I create a frame with a context that contains both a link to an external context and an inline context, framing fails.

However, if I explicitly add a base, framing works. Have I misinterpreted the spec again, or is this an actual bug? It appears to work on the JSON-LD Playground: See this permalink.

Failing Example

require 'linkeddata'

graph = RDF::Graph.new
graph << [RDF::URI("http://www.museum.com/fish"), 
          RDF.type, 
          RDF::URI("http://www.cidoc-crm.org/cidoc-crm/E55_Type")]

unframed_json = JSON::LD::API::fromRdf(graph)


# Using this frame:
frame = {
  "@context"=> [
    "https://linked.art/ns/context/1/full.jsonld",
    {"crm" => "http://www.cidoc-crm.org/cidoc-crm/"}
  ]
}

# This works
puts JSON::LD::API.frame(unframed_json, frame, base: "http://www.example.com")

# But this doesn't.
begin
  puts JSON::LD::API.frame(unframed_json, frame)
rescue JSON::LD::JsonLdError::InvalidBaseIRI => e
  puts "This doesn't work: #{e}"
end


# But using this frame:
frame = {
  "@context"=> [
    {"crm" => "http://www.cidoc-crm.org/cidoc-crm/"}
  ]
}
# Both of these work
puts JSON::LD::API.frame(unframed_json, frame, base: "http://www.example.com")
puts JSON::LD::API.frame(unframed_json, frame)

Hello,

I am trying to use the Format class instances to describe the available formats in dbpedia lite, instead of hard coding them into my app.

However the #name method doesn't work for the JSON::LD::Format class:

$ irb
irb(main):001:0> require 'rubygems'
=> false
irb(main):002:0> require 'json/ld'
=> true
irb(main):003:0> JSON::LD::Format.name
=> "LD"
irb(main):004:0> JSON::LD::Format.file_extension
=> [:jsonld]
irb(main):005:0> JSON::LD::Format.content_type
=> ["application/ld+json", "application/x-ld+json"]

Perhaps it is easiest just to overload the #name method?

Hi,

The rdf executable does not handle the --no-compact-to-relative option as described in the help.

rdf compact --canonicalize --output-format=jsonld --compact-arrays  --processingMode=json-ld-1.1 --no-compact-to-relative /data/rdf/208700.jsonld 
rdf: invalid option: --no-compact-to-relative

the positive option is accepted:

 rdf compact --canonicalize --output-format=jsonld --compact-arrays  --processingMode=json-ld-1.1 --compact-to-relative /data/rdf/208700.jsonld 
rdf: Compacting requires a context

kr,
Bert

When extracting JSON-LD from a webpage, the root always seems to be a blank node.

graph = RDF::Graph.load('https://training.galaxyproject.org/training-material/topics/assembly/tutorials/debruijn-graph-assembly/tutorial.html', format: :jsonld)
puts graph.dump(:jsonld, validate: false, standard_prefixes: true)

=>

{
  "@context": {
    "schema": "http://schema.org/",
    "dc": "http://purl.org/dc/terms/",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@graph": [
    {
      "@id": "_:g457280",
      "@type": "schema:LearningResource",
      "dc:conformsTo": {
        "@id": "https://bioschemas.org/profiles/TrainingMaterial/1.0-RELEASE"
      },
...

This seems to be the case even if I explicitly set the base_uri option.

Is there a way to read in the triples such that the subject is the URL of the page? Or if not, is there a way for me to know what the root node will be so that I can query properties only from the top-level resource?

I've tried various ways of reading in the triples using both the RDFa and JSON-LD readers, from local files and from remote URLs, and with or without the base_uri and base options set.

The method Fixtures::SuiteTest::Entry#documentLoader sometimes fails when it grabs test-suites. The content_type from the response https://github.com/ruby-rdf/json-ld/blob/develop/spec/suite_helper.rb#L256 is sometimes nil.

When content_type is nil, then the call to start_with? fails here
https://github.com/ruby-rdf/json-ld/blob/develop/spec/suite_helper.rb#L266

This is the stack trace I see for one failing spec:

  135) JSON::LD test suite Transform JSON-LD to RDF toRdf-0118-in.jsonld: produce generalized RDF flag
     Failure/Error: t.run self
     NoMethodError:
       undefined method `start_with?' for nil:NilClass
     # ./spec/suite_helper.rb:266:in `block (2 levels) in documentLoader'
     # ./spec/suite_helper.rb:252:in `block in documentLoader'
     # ./spec/suite_helper.rb:250:in `documentLoader'
     # ./spec/suite_helper.rb:60:in `block (2 levels) in <class:Entry>'
     # ./spec/suite_helper.rb:121:in `run'
     # ./spec/suite_to_rdf_spec.rb:12:in `block (5 levels) in <top (required)>'

It seems that json-ld is not caching context documents, and I strongly feel it should. I was temporarily blocked from w3c due to this lack of caching.

I see in the gemspec that there is a development dependency on open-uri-cached; however, i believe the actual code in question is doing a Net::HTTP.get request
https://github.com/ruby-rdf/json-ld/blob/develop/lib/json/ld/api.rb#L463
called from
https://github.com/ruby-rdf/json-ld/blob/master/lib/json/ld/context.rb#L292

so the open-uri-cached gem is perhaps not in play. In any case, I think this should be a production default.

Thanks!

• Naomi

I am using the following command to serialize a turtle file to json-ld:

rdf serialize --input-format turtle https://frob.nl/tmp/gm.ttl --output-format jsonld

In the output neither the dc: nor senet: prefixes are used. This did work some time ago (I think installed the linkeddata gem in february 2012), the output then was https://frob.nl/tmp/gm-old.jsonld , with the current version the output is
https://frob.nl/tmp/gm-current.jsonld.

I run the program:

$ jsonld --expand in.json 
Error in -stdin-
/Users/user/.gem/ruby/2.4.0/gems/json-ld-2.1.3/lib/json/ld/context.rb:653:in `create_term_definition': invalid term definition: @context not valid in term definition for JSON-LD 1.0 (JSON::LD::JsonLdError::InvalidTermDefinition)

I would expect that the error was Error in in.json. Hopefully maybe even the file line and column in which the error happens (or JSON path/pointer or something). It might be that there are multiple @contexts present in a file. From the error message it is hard to kw which one is a problem.