Re: JSON-LD Basic

On Jun 27, 2011, at 8:25 PM, Manu Sporny wrote:

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?

I just want to be clear in the document, and we should have an example, that a value may be expressed as an array. I think we need a section on property values around 3.5. Perhaps it could be something like the following (from 4.7 of the original spec):

3.5 Multiple Objects for a Single Property

A JSON-LD author can express multiple triples in a compact way by using arrays. If a subject has multiple values for the same property, the author may express each property as an array.

Example
{
...
"@subject": "#joebob",
"nick": ["joe", "bob", "jaybee"],
...
}

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

Reasonable; are you suggesting that we add @vocab and @base to the Basic profile, or would these only be invoked for the advanced profile?

Also, this would come after first determining that the value is to be interpreted as a URI, either for a property or a value, and would come after term (or CURIE) expansion.

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

This would go into a Chaining section, similar to http://json-ld.org/spec/latest/#chaining

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.

Well, values can certainly be literals or items in addition to IRIs. My point was on the suggestion that IRIs SHOULD be a dereferencable URL. This implies that if I have the following:

{ "homepage": "http://manu.sporny.org/"}

that the IRI SHOULD be dereferencable. It may also imply that the IRI SHOULD be an information resource.

With regard to the fragid, if I have the following:

{ "knows": "http://greggkellogg.net/foaf#me" }

Is it making claims about using "#me" as a resource identifier to a subject contained within some representation at "http://greggkellogg.net/foaf"?

I think we're straying too far into semantics, and we should probably be silent on the dereferencability of IRI values. This is a semantic interpretation of the serialization and belongs in a different layer. I'd suggest that we remove the sentence

"JSON objects identified using IRIs should ensure that the IRI is dereferenceable in some way so that machines can find out more about the resource by dereferencing the link."

-- 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/