Question about Object Processing

[Bradley P. Allen]

Working my way through building a non-streaming JSON-LD processor from
the latest draft, and running into the following question about Object
Processing.

Should I assume that a value that is neither:

- an array, an IRI, a blank node, a CURIE nor a key in the active
context

is a literal, and is *not* a term that could be mapped to an IRI using
a __vocab__ prefix?

Consider the following example:

{
"#": {
"__vocab__" : "http://example.org/myvocab#"
},
"@" : "_:bnode1",
"foo" : "bar"
}

I want to avoid having special knowledge in the processor about the
range of properties. Without making the above assumption, I would need
such knowledge to determine whether this is equivalent to:

_:bnode1 <http://example.org/myvocab#foo> <http://example.org/
myvocab#bar> .

or

_:bnode1 <http://example.org/myvocab#foo> "bar" .

Am I off base here? Is this something that can be inferred from the
Processing Algorithm specification?

[Manu Sporny]

On 10/15/10 10:53, Bradley P. Allen wrote:
> Working my way through building a non-streaming JSON-LD processor from
> the latest draft, and running into the following question about Object
> Processing.
>
> Should I assume that a value that is neither:
>
> - an array, an IRI, a blank node, a CURIE nor a key in the active
> context
>
> is a literal, and is *not* a term that could be mapped to an IRI using
> a __vocab__ prefix?

Yes, I believe that is the correct behavior.

> Consider the following example:
>
> {
> "#": {
> "__vocab__" : "http://example.org/myvocab#"
> },
> "@" : "_:bnode1",
> "foo" : "bar"
> }

You don't want "bar" evaluating to "http://example.org/myvocab#bar", but
you do want "foo" evaluating to "http://example.org/myvocab#foo".

> Am I off base here?

I believe that you are correct.

> Is this something that can be inferred from the Processing Algorithm
> specification?

I don't think you could possibly divine that from the spec at this
point. I've logged a bug against the spec to address this issue:

http://github.com/digitalbazaar/json-ld/issues#issue/1

I think the rule for __vocab__ is that it only applies to properties. We
may need __base__ which only applies to subjects and relative URIs
listed in object? Haven't thought that one through yet.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Making Payments Frictionless, Saving Journalism
http://digitalbazaar.com/2010/09/12/payswarm-api/

[Mark Birbeck]

Hi Bradley,

The object can only be a URI or a literal -- it can't be a token or a
CURIE, I'm afraid.

Other than internally quoting literals to ensure the distinction --
e.g., "'bar'" -- it's difficult to see what we can do here.

At some point the context will probably be extended to allow things to
be said about the predicates (such as which of them indicate resources
and which literals), but for now I think we have to say that tokens
and CURIEs don't apply to objects.

Regards,

Mark

[Bradley P. Allen]

Mark- Just to clarify: you are speaking of the object of the derived
triple obtained from Object Processing, and not the key value in the
JSON-LD itself, correct? - thanks, BPA

[Manu Sporny]

On 10/15/10 13:01, Mark Birbeck wrote:
> The object can only be a URI or a literal -- it can't be a token or a
> CURIE, I'm afraid.

I don't see why it can't be a token or a CURIE? If it's not escaped and
is in the context, it's a CURIE/token. If it is escaped, it is not a
CURIE/token. What am I missing?

[Mark Birbeck]

Hi Manu,

Yes, we could say that token and CURIE processing apply to the object
part of a triple, but I have to say that seems very risky.

Let's say we have:

var manu = {
"email": "<msp...@digitalbazaar.com>",
"preferredContactMethod": "email"
};

Then we 'semantify' this using the following context object:

manu["#"] = {
"email": "http://xmlns.com/foaf/0.1/mbox"
};

It works fine for the JavaScript property "email", but not so well
when it comes to the values of other properties, since we never know
whether we are dealing with a literal or a URI.

From the point of view of 'principle of least surprise' I don't think
we can process the occurrence of "email" in the
"preferredContactMethod" property as a token. (And it gets worse when
you throw the default vocabulary in there.)

However, if you are saying that this is an important abbreviation for
you when serialising large files then we could certainly look at
providing a way to allow the use of tokens in objects. One possibility
would be to use the safe CURIE construction to indicate that we are
dealing with a token that needs processing:

var manu = {
"email": "<msp...@digitalbazaar.com>",
"preferredContactMethod": "email",
"a": "[Person]"
};

manu["#"] = {
"email": "http://xmlns.com/foaf/0.1/mbox",
"Person": "http://xmlns.com/foaf/0.1/Person"
};

In the situation where you control the output (such as serialising
large files), that would give you what you want, without giving anyone
else a surprise when they semantify their JavaScript. :)

Regards,

Mark