Expanded form - expand all native types to @value form?

[lanthaler]

In a discussion of issue #114 between @gkellogg, @dlongley, and myself it was also discussed to change the shape of expanded documents to always use the expanded object form. The means, that instead of using just a native datatype as the value of a property, the value of every property (except @id and perhaps @type) would be in expanded object form. So, e.g., the following document

{
  "@context": {
    "ex": "http://example.com/"
  },
  "@id": "http://example.com/expand",
  "ex:t1": 1,
  "ex:t1": true,
  "ex:t3": "t3"
}

would be expanded to

[
  {
    "@id": "http://example.com/expand",
    "http://example.com/t1": [
      {
        "@value": 1
      }
    ],
    "http://example.com/t1": [
      {
        "@value": true
      }
    ],
    "http://example.com/t3": [
      {
        "@value": "t3"
      }
    ]
  }
]

I wouldn't particularly like this as it bloats the document up quite a bit without much (any?) advantages. I believe the overhead (due to the number of necessary object instantiations) would be considerable and don't really see the uniformity that Gregg and Dave see.

[lanthaler]

For the record, here's the full IRC protocol:

[00:17] <taaz> i haven't been doing much coding with json-ld.  dlongley has been doing 
all that fine work lately.  he'll probably be around at some point.
[00:37] <dlongley> gkellogg: (or mlnt) in expanded form , should IRIs in a @graph 
array use @id or not?
[00:38] <dlongley> "@graph": ["foo:bar", ...] or "@graph": [{"@id": "foo:bar"}, ...] ?
[00:41] <gkellogg> In expanded form, I believe they should be expanded.
[00:42] <dlongley> ok, that's what i think as well
[00:42] <gkellogg> This is because the content model allows object.
[00:42] <dlongley> i agree
[00:42] <dlongley> i'll change the latest test
[00:42] <dlongley> that doens't do that
[00:42] <gkellogg> @type and @id are separate, because they only allow a string.
[00:42] <dlongley> agreed
[00:43] <dlongley> actually ...
[00:43] <dlongley> it looks like markus changed it specifically
[00:43] <dlongley> so we should get agreement from him first
[00:43] <dlongley> i thought it was just a new test
[00:43] <dlongley> "Just as in @id and @type, string values in @graph shouldn't be 
expanded to the expanded object form."
[00:43] <dlongley> is his commit message
[00:45] <gkellogg> We should discuss on tuesday. I suppose I could go either way, but 
I think it simplifies the processing to treat @graph just as any other property that 
has @container: @set and @type: @id on it.
[00:45] <gkellogg> Otherwise, it's just more special case code.
[00:45] <gkellogg> Do you want to comment on the commit?
[00:45] <dlongley> sure
[00:53] <mlnt> Sorry.. was away for a while
[00:54] <dlongley> np
[00:54] <mlnt> I don't think that in expanded form @graph values should be expanded to 
expanded form
[00:54] <dlongley> manu also made the point that there might be support for literally 
named @graphs in the future
[00:54] <mlnt> it's the same as for @type
[00:54] <dlongley> and it's already in the N-Quads "spec"
[00:54] <dlongley> though not really used/supported by anyone (i don't think)
[00:55] <dlongley> we should probably be careful to support it just in case.
[00:55] <dlongley> and we can treat @graph like every other property rather than 
special casing it like @type
[00:55] <mlnt> but then we can't drop it in compaction
[00:55] <dlongley> we "allow" objects for @type, but i think strings only really make 
sense there
[00:56] <dlongley> whereas it makes a lot of sense to have objects in @graph
[00:56] <dlongley> we can, as we treat @graph like it has a type coercion rule
[00:56] <dlongley> we could even put that in the initial context
[00:56] <mlnt> agreed.. that's another thing I wanted to clarify.. I think we should 
disallow objects in @type
[00:56] <dlongley> i'm fine with disallowing it ... but how would we enforce that, 
exception?
[00:56] <mlnt> if @graph has a coercion rule it will have the same in expanded output 
(that rule is not stored in the context)
[00:57] <mlnt> so you don't loose that info.. same as in @type
[00:57] <dlongley> well, if it's in the initial context it would
[00:57] <dlongley> it wouldn't have the same expanded form i mean
[00:57] <dlongley> hmm.
[00:57] == fcodvpt [~fconil@2001:660:5001:142:21b:63ff:fea7:217c] has quit [Quit: 
fcodvpt]
[00:57] <dlongley> well, i guess we're special casing it either way.
[00:58] <mlnt> I don't mind either way.. I would just like to keep it consistend in 
compacted/expanded
[00:58] <dlongley> right
[00:58] <dlongley> i
[00:58] <dlongley> i'd prefer consistency as well
[00:58] <dlongley> (with @id) ...
[00:58] <dlongley> but i do see the benefit of not needing @id in compact form ...
[00:58] <mlnt> I think just having strings would make sense since I believe people 
will assume that the value is ALWAYS interpreted as an IRI
[00:58] <dlongley> do we allow adding @type rules to keywords right now?
[00:59] <dlongley> well, again, the problem is that we don't know what the RDF people 
will end up doing with named graphs
[00:59] <dlongley> they already have "literal" in there as a possibility in at least 
one output form "spec"
[00:59] <mlnt> well, for keywords there's not really a difference between 
compacted/expanded form as they don't rely on a context
[01:00] <mlnt> we could always represent literals as @value objects in that case
[01:00] <dlongley> i guess, but that's even more special code
[01:00] <mlnt> why?
[01:00] <dlongley> well, we have to know to output @value for @graph
[01:01] <dlongley> we don't do that with plain literals elsewhere ... or do we?
[01:01] <dlongley> maybe i'm misremembering
[01:01] <dlongley> i thought, in expanded form, you could just use a string for a 
plain literal
[01:01] <mlnt> what do you mean by "we have to know to output @value for @graph"?
[01:01] <mlnt> where?
[01:01] <dlongley> "@graph": [{"@value": "Fred"}, {"@id": "foo:bar"}, ...]
[01:02] <mlnt> --> expanded: "@graph": [{"@value": "Fred"}, "http://foo/bar"}, ...]
[01:02] <dlongley> yes, but someone might author it as just "Fred"
[01:02] <gkellogg> Regarding subject references in @type, I recall that the reason for 
this was because fromRDF may use a different property, which could be coerced to 
@type.
[01:02] <dlongley> and expect that that is a plain literal
[01:02] <mlnt> OR --> expanded "@graph": ["Fred", {"@id": "foo:bar"}, ...]
[01:02] <dlongley> it would be confusing
[01:03] <mlnt> how would you distinguish between an IRI and a literal then? there's no 
way
[01:03] <dlongley> gkellogg: do you mean aliased to @type?
[01:03] <gkellogg> Right
[01:03] <dlongley> gkellogg: and if so ... could we possibly resolve that with the 
flags i suggested in issue #100?
[01:03] <dlongley> mlnt: that's what i'm saying ... it would be confusing.
[01:03] <mlnt> keep in mind that the absence of @context in the document doesn't allow 
you to threat/interpret @graph it differently
[01:04] <gkellogg> It's different. The graph may come in as {"rdf:type": "Foo"}, but 
then have an alias applied in a context when expanding later to "@type".
[01:04] <mlnt> yes, that's why I would suggest we don't expand @graph to @id objects.. 
if someone needs literals he can use @value for that
[01:04] <gkellogg> mint: I really don't see the need to make @graph more of a special 
case than it already is.
[01:05] <dlongley> gkellogg: do you think we need to support that use case ... or 
should we just support converting directly in fromRDF?
[01:05] <dlongley> gkellogg: do we have a similar problem if someone aliases to @id?
[01:05] <gkellogg> dlongley: is the concern that we don't want to allow/encourage 
using subject references in authoring?
[01:05] <mlnt> gkellog it's never mint but with a small L  :-)
[01:05] <gkellogg> perhaps
[01:05] <dlongley> mlnt: but then @graph is backwards from everything else.
[01:05] <dlongley> mlnt: and that would confuse people ...
[01:06] <dlongley> mlnt: normally, a string is interpreted as a plain literal ... not 
an IRI
[01:06] <mlnt> not in @type and @id
[01:06] <dlongley> mlnt: i realize that isn't the case for @type and @id
[01:06] <dlongley> hmm
[01:06] <gkellogg> Perhaps the argument is that @type and @id should also expand to 
subject references.
[01:06] <mlnt> I think we agree that literals are the special case in @graph, do we?
[01:07] <dlongley> gkellogg: well, that's one of the concerns... and if we disallow it 
(via exception) but support choosing any property you want to convert to @type in 
fromRDF it seems that could work
[01:07] <dlongley> mlnt: yes, they are the special case
[01:07] <mlnt> gkellogg: no.. we just change @graph to not expand to @id and keep 
everything else as is
[01:08] <mlnt> dlongley: so, let's make it difficult to express that (@value) and 
simple to express IRIs (just a string)
[01:08] <gkellogg> At this point, I thinks we should make decisions on what simplifies 
the overly-complex algorithms.
[01:08] <dlongley> well, i think the question is this: is it safe to assume that 
giving @graphs literal names will be a corner case?
[01:08] <dlongley> if so ... and it's possible we might not even have to support it, 
then why not just treat @graph like @type?
[01:08] <mlnt> either way we need a way to distinguish between strings and IRIs
[01:09] <dlongley> gkellogg: well, right now we have to special case @type ...
[01:09] <mlnt> supporting @value objects is straightforward - at least in my 
implementation
[01:09] <dlongley> i think it might just be a "@type or @graph" change.
[01:09] <gkellogg> Not quite, unless @type can take a subject definition.
[01:09] <dlongley> mlnt: i don't know if it's that simple ...
[01:10] <dlongley> our expansion algorithm converts {@value: "foo"} into "foo"
[01:10] <dlongley> we'd have to special case it for the @graph property
[01:10] <mlnt> then I don't understand your algorithm.. how do you decide whether the 
document is in expanded form or not?
[01:11] <gkellogg> Maybe we should try to remove special processing for both @graph 
and @type and use a strict mode to check for inappropriate input.
[01:11] <dlongley> i don't make that decision, i just expand ...
[01:11] <dlongley> not sure i understand the question
[01:11] <mlnt> dlongley: {@value: "foo"} -- expand --> "foo" -- expand --> { "@id": 
"foo" } ??
[01:11] <dlongley> yes, like i said, it wouldn't work for @grpah
[01:11] <dlongley> @graph.
[01:11] <dlongley> look at the algorithm we currently have on the API spec.
[01:12] <dlongley> let me get the number
[01:12] <mlnt> yes I looked at it but decided to implement it differently as I found 
it incomplete and too complex
[01:12] <dlongley> http://json-ld.org/spec/latest/json-ld-api/index.html#expansion-
algorithm
[01:12] <dlongley> 2.3.2
[01:13] <dlongley> ok ... well we need to update the spec and get in sync with one 
another
[01:13] <dlongley> does your algorithm not convert {"@value": "foo"} --> "foo" on 
expansion?
[01:13] <mlnt> no
[01:14] <gkellogg> 2.3.2: if @value is the only property or the value of @value equals 
null, replace element with the value of @value.
[01:14] <gkellogg> Doesn't it have to?
[01:14] <dlongley> https://github.com/lanthaler/JsonLD/blob/master/Processor.php#L416
[01:14] <dlongley> your current implementation does
[01:14] <dlongley> (maybe we're miscommunicating?)
[01:16] <mlnt> no.. I'm still working on it... that's not the most recent version
[01:17] <dlongley> ok... so do you think we should always leave @value in expanded 
form?
[01:17] <dlongley> (i'm ok with that i think)
[01:18] <dlongley> gkellogg: would you be ok with striking that one line from the 
expansion algorithm and leaving @value?
[01:18] <gkellogg> Yes, I can see the /value/ in keeping @value :)
[01:18] <dlongley> =)
[01:18] <mlnt> :-)
[01:18] <gkellogg> More normal is better
[01:18] <dlongley> i agree
[01:19] <dlongley> that's what i used to do (i think)
[01:19] <gkellogg> So, in expanded form, it's never the case that the value of a 
property is a string or an array of strings.
[01:19] <dlongley> i'm ok with that
[01:19] <gkellogg> s/of strings/including string/
[01:19] <dlongley> well
[01:20] <gkellogg> Except for @id and @type.
[01:20] <dlongley> i think the argument is that @type and @id would still be different
[01:20] <dlongley> right
[01:20] <mlnt> gkellogg: Not sure I follow you "So, in expanded form, it's never the 
case that the value of a property is a string or an array of strings."
[01:21] <dlongley> with the exception of @id and @type (and possible @graph, we're 
still debating), every other property, in expanded form, will never be a string or an 
array of strings.
[01:21] <mlnt> why not?
[01:21] <dlongley> every literal will have the form {"@value"...}
[01:21] <gkellogg> "foo": "bar" would always expand to "foo": {"@value": "bar"}
[01:21] <dlongley> and every IRI will have the form {"@id" ...}
[01:21] <mlnt> why that?
[01:21] <dlongley> (or bnode)
[01:22] <dlongley> because we're not removing @value when expanding.
[01:22] <dlongley> for plain literals.
[01:22] <dlongley> (same goes for native types)
[01:22] <dlongley> when expanding "foo", 5, 3.23, true, false
[01:22] <mlnt> we are just not removing it for @graph as the (implicit) type of @graph 
is @id and removing the @value would convert the literal to an IRI - this doesn't 
automatically apply to all other properties
[01:22] <gkellogg> The question is, whey keep @id and @type different?
[01:22] <dlongley> you get: {"@value": "foo"}, {"@value": 5} ... etc.
[01:23] <dlongley> mlnt: ok, this is why we're confused, it sounded to us like you 
were saying you don't remove @value *AT ALL* any more.
[01:23] <dlongley> and we (gregg and I) were agreeing that that seemed like a good 
idea.
[01:23] <dlongley> because it makes expanded form more regular.
[01:23] <mlnt> oh ok, now I understand.. no I was till now just speaking of @graph
[01:24] <dlongley> ok
[01:24] <dlongley> so... what do you think about just always using @value (for all 
properties. ... with possible exceptions for @id, @type and/or @graph)?
[01:24] <dlongley> (exceptions to be discussed shortly)
[01:24] <mlnt> don't like that idea
[01:24] <dlongley> why not?
[01:25] <mlnt> because expanded form is actually quite useful to work with
[01:25] <dlongley> why would that change?
[01:25] <dlongley> in fact, i would expect it to be more useful/easier to code to 
because it's more consistent.
[01:25] <dlongley> you *always* know there's a @value there
[01:26] <dlongley> foo is always an object, and it either has '@id' or '@value'.
[01:26] <mlnt> hmm... that's actually true.. I think I wanted to keep native data 
types where possible
[01:26] <mlnt> and just need to worry when they are typed to something
[01:27] <dlongley> to be clear, this doesn't mean eliminating native datatypes
[01:27] <mlnt> yes I understand what you mean
[01:27] <dlongley> "@value": 5
[01:27] <dlongley> ok
[01:27] <mlnt> hmm.. still not sure this is the right way to go
[01:27] <dlongley> so does this mean you're for or against always having @value in 
expanded form?
[01:28] <dlongley> what's holding you back?
[01:28] <dlongley> here are the advantages:
[01:28] <dlongley> 1. regular form
[01:28] <dlongley> 2. consistent algorithm for dealing with @graph if we support 
literals there
[01:28] <mlnt> because it bloats up expanded output quite a bit and I will still need 
to check if there's a type or not (reps. check the type of @value)
[01:29] <mlnt> when it's an object I will know it's "something" special
[01:29] <dlongley> well
[01:29] <dlongley> right.
[01:29] <mlnt> I don't see why this would make @graph more consistent
[01:30] <dlongley> if the expansion algorithm never removes @value
[01:30] <dlongley> and neither does @graph
[01:30] <dlongley> they are consistent with one another.
[01:30] <dlongley> if the expansion algorithm *only* removes @value if NOT @graph
[01:30] <dlongley> they are in conflict; it is a special case.
[01:31] <mlnt> I think expansion should also remove @value if there's no type or 
language attached to it
[01:31] <mlnt> so plain literals should always become strings in expansion
[01:31] <dlongley> right, but if you do that ...
[01:31] <dlongley> then you have to special case for the property @graph.
[01:31] <dlongley> except for @graph.
[01:31] <dlongley> right?
[01:32] <mlnt> well, but that's due to RDF which doesn't allow literals as types or 
ids
[01:32] <mlnt> and I actually didn't know that graph does
[01:32] <dlongley> http://sw.deri.org/2008/07/n-quads/
[01:33] <dlongley> go to section 3.
[01:33] <dlongley> the grammar for context (graph) includes literal
[01:33] <dlongley> i don't think anyone is actually using that
[01:33] <dlongley> but we don't know if people will want it or what's really going on 
with the whole graph discussion/direction.
[01:33] <mlnt> not a standard and 4 years old :-)
[01:33] <dlongley> :)
[01:34] <dlongley> i dont' think that literals should be supported there ...
[01:34] <gkellogg> RDF WG's doing something with NQuads now, I think.
[01:34] <dlongley> but we might want to cover our bases.
[01:34] <gkellogg> It's sort of needed as they're doing TriG.
[01:34] <gkellogg> I think that as a syntax we shouldn't worry about the ability to 
express things that might not be RDF. That's an issue for the RDF content model.
[01:35] <gkellogg> Generating a literal for a subject, predicate, object, or context 
could be fine syntax, but just might not result in valid RDF.
[01:35] <dlongley> right
[01:35] <gkellogg> There's current discussion about having literals in the subject 
space, as well as having an inverse form of predicates
[01:35] <gkellogg> (on rdf-comments)
[01:36] <dlongley> ok ... let's see if we can decide on this now or not ...
[01:36] <dlongley> should we always use @value in expanded form?
[01:36] <dlongley> or should we not decide that just yet?
[01:36] <gkellogg> Well, Ivan's coming down to allowing RDF syntaxes from being able 
to express such things now.
[01:37] <gkellogg> I'd say that using @value is more consistent for expanded form. It 
creates a more stable basis for performing compaction and framing.
[01:37] <mlnt> if I have to decide now I would say no (to always use @value)
[01:38] <dlongley> i think expanded form is already a verbose format (somewhat 
intentionally); and keeping the form more regular is a positive step.
[01:38] <dlongley> it's easier on algorithms and easier to understand
[01:38] <gkellogg> It is separate from @graph, though. I'd like to make @graph 
consistent with other expansion algorithms.
[01:38] <dlongley> ok, well, it doesn't look like we're going to agree to keep @value 
just yet ...
[01:38] <dlongley> so let's talk about @graph.
[01:39] <mlnt> I would say for @graph we just threat it like a property for which 
there's an @id-coercion (and that coercion is always there)
[01:39] <gkellogg> That argues for expanding to {"@id": "foo"}
[01:39] <dlongley> mlnt: but, to be clear, that requires that we special case inputs 
containing @value, right?
[01:39] <gkellogg> which is what manu, dave and i agree on.
[01:39] <dlongley> gkellogg: right.
[01:40] <mlnt> no, the @id-coercion doesn't get lost during expansion.. same as in @id 
and @type
[01:40] <mlnt> emphasis on is *always* there
[01:41] <dlongley> mlnt: and what do we do about @value?
[01:41] <dlongley> in @graph
[01:41] <gkellogg> I'm concerned that unilateral changes are made that affect the 
semantics. If these are contentious issues, they should be discussed on the call, or 
in email.
[01:42] <dlongley> well, i think we should discuss all this stuff on list and/or on 
the call too, just trying to see where we are
[01:42] <mlnt> @value can't be dropped there as it would change a literal to an IRI
[01:43] <mlnt> let's try to look at the different options
[01:43] <dlongley> mlnt: ok, so for @graph, you would prefer a built-in @id coercion 
for compaction and expansion and a special-case treatment of @value.
[01:43] <gkellogg> Ii think if there's an implicit @type: @id, then it would be clear 
that if a string made it through expansion, it would need to be represented using 
{"@value"}
[01:43] <mlnt> Yes, that's what I think as well
[01:43] <dlongley> right
[01:44] <dlongley> you only remove @value when there is no implicit @type: @id rule.
[01:44] <gkellogg> I believe that the spec is currently consistent about treeing 
@graph as if there's an implicit @type: @id, and it should be expanded to {@id} form.
[01:45] <gkellogg> Which is the case for @id, @type and @graph.
[01:45] <mlnt> we basically have to options: interpret strings in @graph as IRIs or 
plain literals
[01:46] <mlnt> I changed the test because it was contradicting the other tests
[01:46] <gkellogg> What tests did it contradict?
[01:46] <mlnt> keywords are the same before and after expansion (nothing is lost 
during expansion)
[01:46] <mlnt> a compact test that dropped @id
[01:47] <mlnt> in @graph
[01:47] <dlongley> that wasn't a contradiction, however ...
[01:47] <gkellogg> That's consistent with having @type: @id on @graph
[01:47] <dlongley> as we dropped them in compaction, not in expansion.
[01:47] <dlongley> right just for compaction.
[01:48] <mlnt> well the problem is that @graph isn't an ordinary property but a 
keyword
[01:48] <dlongley> it behaves as if there is an initial context with {"@graph": 
{"@type": "@id"}}
[01:48] <mlnt> but you would loose that context in expansion
[01:48] <dlongley> you don't "lose" it ... rather it is an implicit rule
[01:48] <dlongley> it's known that it's a built-in
[01:49] <dlongley> just like you don't lose it with your suggestion
[01:49] <dlongley> of not using @id when expanding
[01:49] <mlnt> which means that {@id: "x"} and "x" are the same
[01:49] <dlongley> either way the information isn't lost because it's part of the 
processing rules
[01:49] <mlnt> it's redundant information
[01:49] <dlongley> both of those would expand to the same thing
[01:51] <dlongley> it's not any different from how compaction works now ...
[01:51] <dlongley> the only difference is where the context information is stored;
[01:51] <dlongley> in the document or as an initial context in the processor.
[01:51] <dlongley> (or really, as a document at a URL we haven't picked yet for the 
initial context)
[01:52] <mlnt> counterquestion: should we replace @value: 4 with just 4 in expansion?
[01:52] <dlongley> if we're removing @value for non-type/non-language literals, yes; 
if not, no.
[01:52] <gkellogg> Depending on @type coercion, probably.
[01:52] <gkellogg> I think we determined that a term that was inconsistent with this 
wouldn't be used anyway.
[01:52] <dlongley> it's the same question we were discussing earlier, in my view
[01:53] <mlnt> not for @graph but for a property without type/lang mapping?
[01:53] <dlongley> it's just the same should @value be removed or not question.
[01:53] <dlongley> right.
[01:53] <dlongley> it's the same question; and i've come around to thinking we should 
just use a more regular output ...
[01:53] <dlongley> which means always using @value for literals.
[01:53] <dlongley> it doesn't matter if it's a boolean or a string.
[01:54] <mlnt> no, because a property defaults to non-IRI type whereas @graph defaults 
to IRI - at least that was my opinion
[01:54] <dlongley> but, if we decide that we want to drop @value ... (except for 
@graph)
[01:54] <dlongley> then we should consistently drop it as well.
[01:54] <dlongley> there are two issues here:
[01:54] <dlongley> @graph and non-@graph behavior.
[01:55] <dlongley> and what to do with @value when expanding.
[01:55] <gkellogg> ? or string
[01:55] <mlnt> yes and I'm arguing that @id should be dropped for @graph because it 
defaults to IRI and @value should be dropped for non-@graph as it defaults to no type
[01:55] <dlongley> ok, so you're viewing it through the lense of default values
[01:55] <dlongley> hmm.
[01:56] <mlnt> looks as we don't come to an agreement :-)
[01:56] <dlongley> there are two things we want to satisfy:
[01:56] <mlnt> yes.. because that's what we do with @id and @type as well (even though 
we don't allow @value objects there)
[01:56] <dlongley> consistency and ease of use/natural use.
[01:57] <mlnt> agree
[01:57] <gkellogg> IMO, expanded form is not designed for ease of use
[01:57] <gkellogg> ? but for consistency
[01:57] <dlongley> gkellogg: well, it isn't designed for "natural" use.
[01:57] <gkellogg> *everyting* should probably be in expanded form.
[01:57] <gkellogg> including @id and @type
[01:57] <dlongley> because a regular (consistent) format can be seen as easy to use
[01:58] <dlongley> that's what it was originally ...
[01:58] <dlongley> but people didn't like it.
[01:58] <dlongley> they especially took issue with "@id": {"@id": "foo:bar"}
[01:58] <mlnt> including myself
[01:58] <dlongley> brb
[01:58] <gkellogg> well, expanding @id to rely on @id could lead to an infinite depth 
:P
[01:59] <gkellogg> @type doesn't suffer from this problem, though.
[01:59] <mlnt> I'm not sure anymore what you are arguing for regarding @graph - not 
about changing everything else as well :-)
[02:00] <dlongley> back
[02:00] <gkellogg> I'm trying to simplify. But, @graph is different because it can 
take more than an IRI.
[02:00] <dlongley> originally, the purpose of expanded form was to put everything into 
the most regular, verbose format... then there were some special "built-in" rules for 
compaction that everyone (or nearly everyone) would want that would automatically 
coerce things like @ids and @types.
[02:02] <dlongley> however, expanded form has changed somewhat to be a little bit like 
compaction; making certain optimizations like the removal of @id or @value
[02:02] <mlnt> and I still believe it is a very regular form.. just because we use 
native types without wrapping them into an @value doesn't change anything in that 
regard IMO
[02:02] <dlongley> well, what i mean is ...
[02:02] <mlnt> we drop them to keep it regular.. otherwise a plain literal could be 
represented in two ways
[02:02] <dlongley> there's more than one way to specify a value ...
[02:02] <dlongley> and the most verbose form was "expanded form".
[02:03] <dlongley> you can specify the string foo as "foo" or {"@value": "foo"}.
[02:03] <dlongley> if we don't use the "expanded" (large/long) form in expanded form, 
it's a little counterintuitive to me.
[02:03] * gkellogg nods
[02:03] <mlnt> we consolidate that to "foo" in expanded form to reduce the variability
[02:04] <dlongley> it seems to increase the variability to me.
[02:04] <gkellogg> consolidating to {"@value": "foo"} would also reduce variability
[02:04] <dlongley> right.
[02:04] <gkellogg> and increase uniformity
[02:04] <dlongley> and it makes more sense with the idea of it being in "expanded" 
form.
[02:04] <mlnt> why? in expanded output you either have a native type with no lang/type 
attached OR something typed/language tagged
[02:04] <dlongley> if you're expanding everything, why are we compacting some things?
[02:04] <dlongley> the point is to remove optimizations
[02:05] <dlongley> not add them
[02:05] <dlongley> if {"@value": "foo"} were not a legal representation of a plain 
literal
[02:05] <dlongley> i would be just fine with having "foo" be "expanded form"
[02:05] <gkellogg> Note that compacting an expanded document with an empty context 
would yield similar results (other than array collapsing)
[02:05] <dlongley> however, because there are two possible ways to say "foo"
[02:05] <dlongley> it seems to me that the larger/longer one should be what's used in 
"Expanded Form" <--hence the name.
[02:06] <mlnt> there aren't two ways
[02:06] <mlnt> in expanded form
[02:06] <dlongley> there are two ways in JSON-LD.
[02:06] <dlongley> so ... one way is "compact"
[02:06] <dlongley> and another is "expanded".
[02:06] <dlongley> "foo" == short, compact.
[02:06] <dlongley> {"@value": "foo"} == long, expanded.
[02:07] <dlongley> that's where the names originally came from.
[02:07] <dlongley> (i know because i wrote it =) )
[02:07] <mlnt> yes I understand that
[02:07] <gkellogg> and to "expand" {"@value": "foo"} to "foo" is just a bit counter-
intuitive
[02:07] <dlongley> right
[02:08] <mlnt> but do you really wanna blow up expanded output that much? for every 
single value you will have to instantiate an object then
[02:08] <dlongley> the point of having compaction was to allow people to make 
optimizations that change it from expanded form ...
[02:08] <dlongley> the second we start saying "well, we can optimize expanded form"
[02:08] <dlongley> we're not talking about "expanded form" in my view.
[02:08] <dlongley> mlnt: yes.
[02:08] <dlongley> that's the point of it.
[02:08] <dlongley> it's the non-optimized format.
[02:09] <dlongley> it's the regular, non-optimized representation of values/IRIs in 
JSON-LD.
[02:09] <gkellogg> mint: are you worried about runtime memory limitations due to 
allocating more objects?
[02:09] <dlongley> then, you can apply context however you want to optimize what you 
want to.
[02:09] <mlnt> I always saw expanded form as something were all the context processing 
has been done and all IRIs have been *expanded* - not the most verbose representation
[02:09] <dlongley> (and we automatically optimize some things that 99% of people will 
want optimized)
[02:09] <dlongley> i see
[02:10] <dlongley> well, i saw it as a full expansion of the IRIs and the 
format/longest possible syntax representation
[02:10] <dlongley> "no optimizations".
[02:10] <mlnt> maybe we should put this back on to the mailinglist
[02:10] <dlongley> if there are N legal ways to write X in JSON-LD, the most verbose 
is the one used in expanded form
[02:11] <mlnt> I think we are getting nowhere at the moment
[02:11] <dlongley> that's fine.
[02:11] <dlongley> i dont' know if we'll get any other interested participants though! 
:)
[02:12] <gkellogg> I'm sure niklas will have an opinion
[02:12] <mlnt> at least it's documented somewhere and we will have more time to 
formulate our thoughts
[02:12] <dlongley> right

[dlongley]

There are often multiple ways to describe the same value in JSON-LD; the original purpose of "expanded form" was to represent all values in the "longest" or most "expanded" way. There were no optimizations in this form, as these were left to compaction, where the specific optimizations used were specified by the context. By removing @value in expanded form, we've introduced an optimization because it's more "compact" -- and this is counter-intuitive to the purpose of expanded form and somewhat conflates the two forms. I would support always using @value in expanded form for this reason and because I believe it results in a more regular output.

[lanthaler]

I agree that the expanded output should be very predictable and regular, but going as far as putting every scalar in an object is the wrong direction in my opinion. I don't think it will make client code any easier and would also have the disadvantage of increased memory usage due to the plethora of objects that have to be instantiated.

E.g., is it easier to deal with prop1 or prop2 in the example below?

"http://example.com/prop1": [ { "@value": 5 }, { "@value": 6 } ],
"http://example.com/prop2": [ 5, 6 ]

I would argue dealing with prop2 is easier.. Instead of having to check

isInteger(prop->{@value}) && (false == propertyExists(prop, '@type')

a simple isInteger(prop) would do it.

Please note that my argumentation here implies that all objects have to be "compacted" to the most basic representation during expansion - but the code doesn't get much more complex due to that since we already support that. So there should definitely be a unique representation for every value in expanded output. I argue it should be the simplest one and not the most verbose one.

The reasoning behind this is that I expect that a lot of developers will probably never use a language/type and if they do, they will know the consequences.

[lanthaler]

On a related note, something like

{
  "@value": "http://example.com/",
  "@type": "@id"
}

should probably be converted to

{
  "@id": "http://example.com/"
}

during expansion.

[lanthaler]

RESOLVED: In general, for expansion, ensure that all property values are expressed in expanded value form (e.g. {"@value": 5}, {"@value": "foo"}, {"@id": "http://example.com/"}) with the exception of @id and @type.

PROPOSAL: In expanded form, @graph must be expressed in expanded value form (e.g. "@graph": [{"@id": "http://example.com/foo#graph}])

[lanthaler]

The question I ask myself now is why we treat @type different from @graph in expansion.. Especially taking into consideration that we now allow @id objects as the value of @type.

As we already opened the door, we could as well allow what @niklasl wanted to have some time ago:

 ...
  "@type": {
    "@id": "http://example.com/type",
    "label": "Type name",
  }

[lanthaler]

Closing this issue as the specs as well as the relevant tests have already been updated: fdb3371, 4fe0e59, and ff92070