Re: JSON-LD Basic

On 06/25/2011 04:24 PM, Gregg Kellogg wrote:
> Some things need to be more explicit, and we need to be careful that
>  a document evaluated as JSON-LD Basic will have the same meaning 
> when evaluated as JSON-LD Advanced.

Yes, that is certainly a concern.

> The document doesn't specify the range of terms used within a 
> mapping. All examples are simple strings, that may be evaluated as 
> IRIs if there's an @coerce mapping. However, the @type example 
> definitely shows the use of an array to map multiple values to a 
> particular key.

I don't quite follow what you'd like to see added to the spec, Gregg?

> If a value is determined to be an IRI, it may be a relative IRI or 
> term (no CURIEs in JSON-LD Basic). If it is a relative IRI, what is 
> it evaluated with respect to?

Good question.

> For most objects, I'd expect it to be relative to the document's
> URL, but what if a @context contains a @base definition for JSON-LD 
> Advanced? Is there such a thing? Perhaps we need to specify that a 
> JSON-LD Basic document MUST NOT be used with a JSON-LD Advanced 
> @context, to avoid this confusion. We should have some formal 
> language for evaluating values and IRIs. In the current (advanced) 
> spec [1], this includes a description of using @base or @vocab to 
> evaluate a relative IRI, depending on the context.

We could pick reasonable defaults... Thinking out loud:

The base URL for properties is determined in this order:

1. @vocab if it exists
2. the @context URL if one exists
3. the document URL if it exists
4. the JSON-LD namespace: http://purl.org/json-ld/terms# or
   urn:json-ld:PROPERTY

The base URL for relative IRIs in values is determined in this order:

1. @base if it exists
2. the document URL if it exists
3. the JSON-LD namespace: http://purl.org/json-ld/items# or
   urn:json-ld:VALUE

The document URL would have to be provided by the application utilizing
the JSON-LD processor.

https://github.com/json-ld/json-ld.org/issues/2

> Should JSON-LD Basic have any notion of chaining, or is it intended 
> to be an entirely flat model?

I don't think it's a flat model. I think there is a notion of chaining here.

> What about anonymous items? (No named-BNode rat-hole please).

I think anonymous items make sense for JSON-LD Basic. We want people to
be able to write:

{
   "@context": "http://example.org/mycontext",
   "name": "Justin Bieber",
   "made":
   {
      "@type": "Album",
      "title": "My World 2.0"
   }
}

(Yes, I actually had to look up Justin Bieber's discography to write
this example). :P

> The documentation on Subject indicates that the value should (or 
> SHOULD) be a dereferencable URL. I presume this is true for other IRI
> property values as well. What about values with fragids? Does this
> imply some index into the referenced document, perhaps to an item
> that has an equivalent IRI definition. This follow-your-nose concept
> is basically what Kingsley's been asking for, I believe.

We could go two ways on this that I can see: Ignore properties/values
that can't be mapped to an IRI. Or ensure that all properties/values can
be mapped to an IRI. I'd prefer we do the latter.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Tuesday, 28 June 2011 03:25:53 UTC