Manu Sporny: Anything else we should discuss today? [scribe assist by Manu Sporny]

Gregg Kellogg: Let's discuss .objectify() vs. .frame() [scribe assist by Manu Sporny]

Gregg Kellogg: Markus wanted to look at ISSUE-120 again - expansion and @type [scribe assist by Manu Sporny]

Manu Sporny: i also spoke with linclark, some of that info is in the jsonld irc channel [scribe assist by Dave Longley]

Manu Sporny: I spoke w/ Lin Clark - she has an interesting use case that we should discuss. [scribe assist by Manu Sporny]

Manu Sporny: let's discuss some of the issues that have come up before the w3c publication in the rdf working group [scribe assist by Dave Longley]

Manu Sporny: we're pretty much set to go

Manu Sporny: then we need everyone to do their IPR coverage

Manu Sporny: https://dvcs.w3.org/hg/json-ld

Manu Sporny: the IPR stuff means a blanket statement that one has no issues regarding patents when going forward

Manu Sporny: we must use the tool for this for the legal stuff to become valid

Manu Sporny: any other questions re. W3C FPWD publication

Manu Sporny: markus, you had a question re #120?

Markus Lanthaler: why do we support objects as value of @type at all?

Markus Lanthaler: the reasoning says that the value space is different, but the decision to throw away data seems contradictory

Manu Sporny: the only thing @type is looking for is a value to interpret as an @id

Manu Sporny: in order to make the algorithm more accepting, we allow an object but only keep the value of @id

Markus Lanthaler: I'm find with both ways, but not a combination

Manu Sporny: keeping the data adds lots of complexity, throwing an error is unnecessary since it's easy to get the value of @id from the object..

Manu Sporny: we need a better reason for throwing an error than that otherwise we discard the other data in the @type object

Manu Sporny: it makes the algorithm more complex than necessary if we throw an error in this corner case

Manu Sporny: we have plenty of other corner cases where we throw an error

Markus Lanthaler: we have callbacks, but we don't define what they do

Manu Sporny: do you rather see that the callback controls recovery instead of automatic recovery?

Dave Longley: that would be fine with me (explicit callback recovery)

Dave Longley: Markus makes a good point that other things have to be considered as well. if an object is there, callback controls recovery

Gregg Kellogg: in the absence of a callback, I'd like the current recovery

Gregg Kellogg: the narrow use case, having RDF data transferred over, with a type in expanded form, and when doing compaction I want to use @type, this would be beneficial default behaviour

Dave Longley: so the use case is fromRDF not using @type, but wants @type in compacted form?

Manu Sporny: the other (stronger) reason is that we don't want to err out where it's easy to recover (it's the html5 behavior)

Dave Longley: we have a similar problem with @id

Gregg Kellogg: it's different

Manu Sporny: there could be something like that in the future; in the mean time (going to REC) we need to work this out

Markus Lanthaler: currently there is no JSON-LD out there, so it's better to not support it until it appears

Dave Longley: to we have real data like this?

Gregg Kellogg: I think it was an observation from working with external sources

Niklas Lindström: It's hard to reason too much about this w/o looking at concrete cases - part of this discussion cropped up a few months ago when we discussed whether it was possible to represent the RDF type like a general relation, just like any other property. [scribe assist by Manu Sporny]

Markus Lanthaler: as far as I remember this came up before we allowed rdf:type not to be automatically to @type in fromRDF()

Niklas Lindström: I've seen some need for this - for example - Elastic Search - you want an IRI for the type or perhaps a keyword and /also/ some kind of label in different languages because people want to search for it. [scribe assist by Manu Sporny]

Niklas Lindström: If you declare rdf:type in your context... it may not be coerced like @type. I think this works if you create an expanded form fromRDF() and define a term forrdf:type in your context when you compact. [scribe assist by Manu Sporny]

Gregg Kellogg: rdf:type a rdf:Property .

Niklas Lindström: From my point of view - I'm fine w/ throwing an error - that we don't allow this form. There should be means for recovering. [scribe assist by Manu Sporny]

Niklas Lindström: I do think that what we have right now is enough, explicit recovery is enough in this case. [scribe assist by Manu Sporny]

Markus Lanthaler: { "@id": "rdf:type", "@type": "rdf:Property" }

Gregg Kellogg: perhaps if we use the expanded form in all the cases where @id isn't applicable, to not lose information

Manu Sporny: gregg, can you write this down in the issue 120?

Gregg Kellogg: sure

Gregg Kellogg: Regarding .objectify() - I find framing very confusing to use right now

Gregg Kellogg: it's hard to predict

Gregg Kellogg: if I can use objectify instead, I have a surface type api, where everything is linked and I can access what I want in a very simple manner

Josh Mandel: (Re: potential search mechanisms, have folks seen: http://jsonselect.org/#tryit ?)

Manu Sporny: I agree that it is complex and difficult to understand how to use the complex stuff

Manu Sporny: we can't remove framing until we have a good replacement. objectify would probably be that

Josh Mandel: I (clearly) also found framing difficult to use, which is why I coded up objectify() in the js library...

Niklas Lindström: I generally agree that framing is difficult - I do have some use cases for framing. [scribe assist by Manu Sporny]

Niklas Lindström: .objectify() feels like the way to distinguish JSON-LD usage from regular JSON usage... JavaScript has all of the requirements in place to make .objectify() work well... [scribe assist by Manu Sporny]

Niklas Lindström: If you are using JSON-LD in a programmatic environment, it makes more sense to have an API that creates a graph structure of the objects within... because they are linked. It feels like a bit of a waste to not do that. This is the way I've used RDF previously in object mappers... we should be using references. The context definition is a good way to navigate Linked Data in general. [scribe assist by Manu Sporny]

Niklas Lindström: One thing - I'm not sure about the name .objectify() - it might not capture the essence... I would use .toGraph() or .graphify() - just a detail, but if we're going forward with this, I wanted to raise this. [scribe assist by Manu Sporny]

Markus Lanthaler: decode()??

Josh Mandel: Yes, I just made up the name `objectify` because it sounded cute and I needed to call it something.

Gregg Kellogg: There is an alternate meaning of Linked Data here - you're linking your data internally to create a real graph. [scribe assist by Manu Sporny]

Niklas Lindström: There is something in rdflab - my play area for code on github - I've added something that we may want to discuss - reverse relations... which makes navigating an RDF vocabulary very easy. The thing that I noticed was that this structure I got was interesting in that in-memory graphs in RDF are more triple centric. This is just linked objects in a graph, and that felt much more natural. The triple view of things could be created as an iterator. [scribe assist by Manu Sporny]

Niklas Lindström: This 'shape' felt much more natural... maybe this would fit in well with projections in the RDFa API. [scribe assist by Manu Sporny]

Niklas Lindström: To back up quickly - the case where .frame() is useful - which is the case where I mostly use JSON-LD - which is to index stuff in elastic search. In that case, I didn't use the framing algorithm (I used an expand as much as I can algorithm... always rooted in current subject resource, which I track), I have very advanced search needs. [scribe assist by Manu Sporny]

Niklas Lindström: I need to search for things linking to and from that document. [scribe assist by Manu Sporny]

Dave Longley: I agree with a lot of this - including naming - perhaps .connect()?

Dave Longley: also a query mechanism is good

Dave Longley: but we have to make sure that code don't end up cycling indefinitely (but that can probably be prevented anyway)

Dave Longley: it's important not to call e.g. expand on an "objectified" structure

Dave Longley: some of the power in framing is available with e.g. @container, but some cases might still need to be supported to adapt data to current patterns

Markus Lanthaler: is the question either or, or can they complement each other?

Dave Longley: it should be noted that non-GC languages and objectify might not work as well

Josh Mandel: http://jsonselect.org/#tryit

Josh Mandel: JSON-select could potentially be used for querying

Niklas Lindström: I used the prototype-based features to be clones of the actual objects - this makes the resulting graph object serializable by calling .toJSON() on it. [scribe assist by Manu Sporny]

Josh Mandel: Well, except for cycles. [scribe assist by Manu Sporny]

Niklas Lindström: The clones have replaced the .toJSON() message with null - it skips cycles - expands into a tree again. [scribe assist by Manu Sporny]

Dave Longley: it might be ambiguous in general though

Gregg Kellogg: flatten is the key to get it to work

Markus Lanthaler: how do you enter the graph?

Manu Sporny: we need to explore whether we can completely replace framing with objectify in usages, and if/how they complement each other

Gregg Kellogg: are we continuing in the github tracker?

Manu Sporny: yes, we can continue to use it

Gregg Kellogg: how to get github to notify the mailing list (not only the people)?

Manu Sporny: the w3c tracker doesn't either; we can create a script

Manu Sporny: it's important, and I think we can solve it

Manu Sporny: and I suspect we agree that gh:s tracker is the better one?

Gregg Kellogg: although the w3c tracker works well with irc (but there's probably a means with gh as well)

François Daoust: bye

David I. Lehn: bye