Re: Odd relative IRI in playground output

On Feb 22, 2014, at 10:18 AM, Dave Longley <dlongley@digitalbazaar.com> wrote:
> 
>> On 02/22/2014 06:55 AM, Markus Lanthaler wrote:
>>> On Saturday, February 22, 2014 3:25 AM, Gregg Kellogg wrote:
>>> This must relate to the default base used by the playground, but when I
>>> run it with my own processor (without specifying a base IRI), I don't
>>> see the relative IRI.
>>> 
>>> Basically, it's compacting the following:
>>> 
>>> {
>>>  "@context": {
>>>    "@vocab": "http://schema.org/",
>>>    "url": {
>>>      "@type": "@id"
>>>    }
>>>  },
>>>  "@type": "Movie",
>>>  "@id": "http://code.sgo.to/movies/123",
>>>  "name": "Dan's schema.org presentation",
>>>  "operation": [
>>>  {
>>>    "@type": "WatchAction",
>>>    "@id": "",
>>>    "actionStatus": "proposed",
>>>    "actionHandler": {
>>>      "@type": "WebPageHandler",
>>>      "url": "/movies/123/watch"
>>>    }
>>>  }]
>>> }
>>> 
>>> using an empty context and getting the following:
>>> 
>>> {
>>>  "@id": "http://code.sgo.to/movies/123",
>>>  "@type": "http://schema.org/Movie",
>>>  "http://schema.org/name": "Dan's schema.org presentation",
>>>  "http://schema.org/operation": {
>>>    "@id": "./",
>> 
>> This is correct
>> 
>> 
>>>    "@type": "http://schema.org/WatchAction",
>>>    "http://schema.org/actionHandler": {
>>>      "@type": "http://schema.org/WebPageHandler",
>>>      "http://schema.org/url": {
>>>        "@id": "../movies/123/watch"
>> 
>> Just as this is: /movies/123/watch (absolute path) and /movies/123/watch
>> (relative path) are equivalent if the base IRI is
>> http://json-ld.org/playground/ 
>> 
>> Dave, I just noticed that I get different results if I run this in IE11.
>> Looks like the base IRI isn't set in that case. Could you verify that?
> 
> Yeah, I'll grab an IE11 VM when I get a chance and look into it. It's
> always something with IE.
> 
>> 
>> 
>>>      }
>>>    },
>>>    "http://schema.org/actionStatus": "proposed"
>>>  }
>>> }
>>> 
>>> However, mine returns the following:
>>> 
>>> {
>>>  "@id": "http://code.sgo.to/movies/123",
>>>  "@type": "http://schema.org/Movie",
>>>  "http://schema.org/name": "Dan's schema.org presentation",
>>>  "http://schema.org/operation": {
>>>    "@id": "",
>>>    "@type": "http://schema.org/WatchAction",
>>>    "http://schema.org/actionHandler": {
>>>      "@type": "http://schema.org/WebPageHandler",
>>>      "http://schema.org/url": {
>>>        "@id": "/movies/123/watch"
>>>      }
>>>    },
>>>    "http://schema.org/actionStatus": "proposed"
>>>  }
>>> }
>> 
>> The difference is that you process the data without a base IRI, i.e., all
>> IRI processing is turned off. To achieve the same in the playground, just
>> add a @base: null to the context. You will get the same result when
>> compacting. You can see the differences when converting to N-Quads. As it
>> can't expand those relative IRIs, it drops some triples.
> 
> Markus is right. Gregg, if you want to see if your parser matches the
> playground output, set base in the API options to:
> http://json-ld.org/playground/

I'm sure it would, as we actually have tests for that, I believe. Any, I'll verify later. For some reason, I hadn't considered that it would use that pages URL for base, but of course you could see why an in-browser processor would.

I suggest using something else, but not have it be dereferencable; I feel sorry for anyone owning example.com or example.org :)
>> --
>> Markus Lanthaler
>> @markuslanthaler
> 
> 
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.

Received on Saturday, 22 February 2014 19:46:11 UTC