Unwrapped IRIs as objects: malformed JSON-LD?
Bradley Allen
into the following issue.
In Section 5.1, we read: "Wrapping IRIs with the < and > characters
are only necessary when IRIs are specified as objects."
In Sections 2.3, 3.3 and 7.1 we have examples of JSON-LD where object
IRIs are *not* wrapped.
The example in 2.3 shows an unwrapped IRI as the rdf:type of the
described resource, but it is unclear from the context of the section
whether the JSON shown is intended to be JSON-LD, or simply an example
of how "machines could automatically expand the terms to something
meaningful and unambiguous."
However, the JSON-LD example in 3.3 contradicts Section 5.1, with the
rdf:types of http://purl.oreilly.com/works/45U8QJGZSQKDH8N and
http://purl.oreilly.com/products/9780596802189.EBOOK shown as
unwrapped IRIs.
Finally, for the example in 7.1, it could be assumed that type
coercion provides the information necessary to disambiguate the
unwrapped IRI that is the homepage for the described resource, but
that is not explicitly stated, and what's there on the face of it
contradicts Section 5.1.
So the question I have is: are the above examples incorrect in the
latest draft, or am I misinterpreting the statement in Section 5.1?
What I want to read there is "Object IRIs must be wrapped with the <
and > characters."
I want the examples to be considered incorrect, because if not, I
believe one consequence would be to require type coercion (or some
other approach) to disambiguate a literal from a relative IRI as an
object.
In other words, I want the following JSON-LD ...
{
"#": { "#base": "http://www.t4gm.info/concept/", "skos":
"http://www.w3.org/2004/02/skos/core#" },
"a": "skos:Concept",
"@": "<t4gm-4-dash-h-clubs>",
"skos:broader": ["<t4gm-clubs>", "<t4gm-youth-organizations>"],
}
... to be processed into RDF equivalent to the following N-Triples ...
<http://www.t4gm.info/concept/t4gm-4-dash-h-clubs>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/2004/02/skos/core#Concept> .
<http://www.t4gm.info/concept/t4gm-4-dash-h-clubs>
<http://www.w3.org/2004/02/skos/core#broader>
"<http://www.t4gm.info/concept/t4gm-clubs>" .
<http://www.t4gm.info/concept/t4gm-4-dash-h-clubs>
<http://www.w3.org/2004/02/skos/core#broader>
"<http://www.t4gm.info/concept/t4gm-youth-organizations>" .
... without having to resort to type coercion. - cheers, BPA
Bradley P. Allen
http://bradleypallen.org
Manu Sporny
> I'm working on adding support for #base to json_ld_processor, and ran
> into the following issue.
>
> In Section 5.1, we read: "Wrapping IRIs with the < and > characters
> are only necessary when IRIs are specified as objects."
>
> In Sections 2.3, 3.3 and 7.1 we have examples of JSON-LD where object
> IRIs are *not* wrapped.
That had to do with some uncertainty with where it was necessary to wrap
IRIs and where it wasn't. We just had a fairly long discussion about
this in our company and came to the following conclusion:
We should get rid of the requirement of wrapping IRIs in '<' and '>' and
depend on type coercion to accomplish that. This would bring the way
that we express IRIs in line with the other parts of JSON-LD.
Ideally, I think that this is what we want (assume this context for the
example):
"#" :
{
"xsd": "http://www.w3.org/2001/XMLSchema#",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"#types":
{
"homepage": "xsd:anyURI",
}
}
and this is your JSON-LD markup:
{
"@": "http://example.org/people#brad",
"homepage": "http://example.org/webpages/bradley-allen.html"
}
This would be the resulting triple in N3 format:
<http://example.org/people#brad>
<http://xmlns.com/foaf/0.1/homepage>
<http://example.org/webpages/bradley-allen.html> .
Note how both the value in '@' was converted to an IRI as was the object
without the need for '<' and '>'.
Here are some of the changes that would need to happen in order to make
this type of processing possible:
1. We'd need to accept type coercion as a mandatory part of JSON-LD.
2. These JSON-LD keywords always coerce to an IRI: '@' and 'a'.
The algorithm for processing JSON-LD property-object entries to N3 would
be something like this:
1. If an entry for type coercion for the specified property exists,
coerce the object value to a string and append the type to the
object's value. This basically means, copy the data as-is and
tack on the type to the end of the data.
2. If a JSON type is expressed, such as a double, or an integer,
coerce the object value to a string and append the correct xsd
type to the end of the string.
3. Detect if there is a microsyntax specified for type information
such as xsd:dateTime or xsd:date, perform ^^ parsing.
4. Check if there is any language information specified, perform
'@' language tag parsing.
5. If none of the other steps apply, the object value is a plain
literal.
Our developers really didn't like the fact that they had to parse
micro-syntaxes for common JSON markup. They're used to specifying IRIs
as plain strings and having to wrap/unwrap the '<' and '>' from IRIs
when working with the data in web apps felt very unnatural to them.
> So the question I have is: are the above examples incorrect in the
> latest draft, or am I misinterpreting the statement in Section 5.1?
> What I want to read there is "Object IRIs must be wrapped with the <
> and > characters."
Apologies for that - I've been conflicted about this particular issue
and only today did we get something sorted out that might work.
This may make Richard Cyganiak happier since we need less microsyntax
stuff in the JSON and since this would also allow JavaScript developers
to use the JSON-LD data without any changes. The down-side is that you
now have to specify type coercion rules for objects that you want to be
IRIs. Don't know if people on here are unwilling to make that trade-off?
Thoughts?
-- 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/
Bradley Allen
explicitly specify type coercion for each and every relation. The
context and profile will consequently expand and from the perspective
of human review, eyeballing the document would require
cross-referencing to determine how something is to be resolved,
Additionally, in this scenario, the relative IRI problem becomes one
that could lead to a lot of inadvertent bugs if people aren't
religiously typing their relations appropriately. Both of these mean
that from a human factors perspective the serialization moves more
towards the problems seen in the complexity of previous JSON
serializations.
All due respect to your development team, but this places a cognitive
burden on the producers of the data to save what should be a
relatively trivial amount of processing, though to be fair your
emphasis on streaming might be impacting this judgment. Is that really
worth the impact on ease of adoption?
Another question: is xsd:anyURI the right type for an arbitrary IRI?
I'm not sure if that really captures the breadth of what could be
expressed with a wrapped IRI.
Bradley P. Allen
http://bradleypallen.org
Mark Birbeck
I understand the motivation, but a very big "-1" to the suggestion. :)
Your developers can of course get rid of the angle brackets on URIs by using
type coercion, in the way that you describe.
But by keeping angle bracket support as well, we allow for JSON-LD
objects that don't rely on type coercion.
I think we have the best of both worlds as things are.
Regards,
Mark
Manu Sporny
> Huh. As you say, the downside with this is that it requires one to
> explicitly specify type coercion for each and every relation.
Yep, I wasn't able to convince our dev team that this was a big
downside. The larger down-side as they saw it was having to decode the
data before having to work with it (such as having to remove <> from
around IRIs).
One solution to that issue, which is along the lines of something that
Mark and I discussed some time ago, was that there would be some sort of
conversion function that would translate the incoming JSON-LD into
something more JSON-native... something that you could use directly in a
web app. So, assume that we have a JSON-LD API, it could have one method:
[NoInterfaceObject]
interface JSONLDParser
{
object parse(
in DOMString jsonld,
in optional removeContext,
in optional IRIsToPlaintext,
in optional removeDatatypes,
in optional removeLanguages);
};
The parse() method takes a JSON-LD encoding and strips out whatever the
JavaScript developer doesn't want. For example, our engineers would
probably want to do this in their browser code:
var mydata = jsonld.parse(apiResult, true, true, true, true);
Then they could use that object like this:
var homepage = data["http://xmlns.com/foaf/0.1/homepage"];
or even like this:
var homepage = data[context("homepage")];
or maybe just dump the object directly into an RDFa API aware environment:
var jsonld = document.data.createParser("jsonld", store);
jsonld.parse(apiResult);
> All due respect to your development team, but this places a cognitive
> burden on the producers of the data to save what should be a
> relatively trivial amount of processing, though to be fair your
> emphasis on streaming might be impacting this judgment. Is that really
> worth the impact on ease of adoption?
I don't think the emphasis on streaming had much to do with the thought
process (at least, nobody mentioned it during the discussion). However,
all the points that you made still stand... hard to tell whether the
trade-off is worth it. Although, both you and Mark seem to remain
unconvinced of the change. I won't change the document, but will fix-up
the spec to add the type coercion algorithm and require '<>' on all IRIs
that are specified as the value in the key-value pairs in JSON.
> Another question: is xsd:anyURI the right type for an arbitrary IRI?
> I'm not sure if that really captures the breadth of what could be
> expressed with a wrapped IRI.
I believe so:
http://www.w3.org/TR/xmlschema-2/#anyURI
If you have a better suggestion, or an example where xsd:anyURI wouldn't
work, please let us know. I think xsd:anyURI covers all IRIs, and URNs,
but I'm not an XML Schema expert.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Rising Swell of Web Application Data
http://digitalbazaar.com/2010/10/30/json-ld/
Manu Sporny
> I understand the motivation, but a very big "-1" to the suggestion. :)
>
> Your developers can of course get rid of the angle brackets on URIs by using
> type coercion, in the way that you describe.
That's true. I guess one of the good things that came out of the
discussion was the algorithm for doing type coercion (not that it was
that complicated of a problem).
The other thing that came out of the mailing list discussion was that we
always wrap IRIs with '<' and '>'.
Now the question is, do we always wrap CURIEs in the object position?
So, do we do this:
"homepage" : "<myhome:page.html>"
or this:
"homepage" : "myhome:page.html"
I think the spec currently states that we do the latter. If you don't
want CURIE processing to happen automatically, you must escape the ":"
character.
However, we may want to minimize the number of rules that people have to
remember. It would be easier to remember:
1. If you are expressing an IRI, use angle brackets.
2. properties, subjects and types are always coerced to an IRI.
instead of:
1. If you are expressing an IRI, use angle brackets.
2. If you are expressing a CURIE, don't use angle brackets.
3. If you are expressing a subject, don't use angle brackets.
4. If you are expressing a type, don't use angle brackets.
If we do the previous, we would allow this:
"<homepage>" : "<myhome:page.html>"
and this:
"homepage" : "<myhome:page.html>"
but not this (the item on the right would be interpreted as a string,
unless it has type coercion applied to it):
"homepage" : "myhome:page.html"
We would also allow this:
"@" : "http://example.org/things#foo"
and this:
"@" : "<http://example.org/things#foo>"
Thoughts?
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.