Manage @list

[jmatsushita]

Currently the @list keyword is not dealt with properly.

For instance when using the levelgraph playground

{
  "@context": {
    "@vocab": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "http://example.org/people#joebob",
  "nick":
  {
    "@list": [ "joe", "bob", "jaybee" ]
  }
}

Reuses the same identifier for blank nodes:

And using .get() returns an empty list.

[jmatsushita]

The same identifier problem comes from using uuid.v1() inside a synchronous loop (yielding the same clockseq) instead of uuid.v4() which uses a RNG.

[BigBlueHat]

I've nearly filed a "switch to UUID's v4" issue multiple times in the last few months. Maybe now's the time?

[BigBlueHat]

Actually. It seems like it's loosing data altogether in some situations. Here's an example annotation that uses a list (from my page-notes webextension thing):

{
  "@context": "https://www.w3.org/ns/anno.jsonld",
  "type": "Annotation",
  "created": "2017-02-02T19:37:13.131Z",
  "body": {
    "type": "Choice",
    "items": [
      {
        "type": "TextualBody",
        "value": "This is where I keep all the things!",
        "language": "en",
        "format": "text/plain",
        "creator": {
          "type": "Person"
        }
      }
    ]
  },
  "target": "chrome-extension://ghmdfebmgdeohmcpjlalclccgjapiild/list/index.html",
  "id": "urn:page-notes:chrome-extension://ghmdfebmgdeohmcpjlalclccgjapiild/list/index.html:2017-02-02T19:37:13.131Z"
}

Using the levelgraph-playground:

1. add that to an empty data set (this is the real reason incognito mode was invented... 😉)
2. open the console
3. run this get request:

db.jsonld.get(
  'urn:page-notes:chrome-extension://ghmdfebmgdeohmcpjlalclccgjapiild/list/index.html:2017-02-02T19:37:13.131Z',
  {"@context":"http://www.w3.org/ns/anno.jsonld"},
  console.log.bind(console));

4. Notice that this object doesn't match the first one--in a couple ways...actually:

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "urn:page-notes:chrome-extension://ghmdfebmgdeohmcpjlalclccgjapiild/list/index.html:2017-02-02T19:37:13.131Z",
  "type": "Annotation",
  "created": "2017-02-02T19:37:13.131Z",
  "body": {
    "type": "Choice",
    "as:items": []
  },
  "target": "chrome-extension://ghmdfebmgdeohmcpjlalclccgjapiild/list/index.html"
}

The items key is now prefixed to as:items and the list is empty. The anno.jsonld defines this for the items alias:

    "items":         {"@type": "@id", "@id": "as:items", "@container": "@list"},

So. Seems @list related at the very least. I'll turn this into a test and mention this issue in a PR. Cheers!

[BigBlueHat]

So @jmatsushita those aren't actually matching UUID's. They're each one character different...on both sides (subject/object) of the graphs...so nothing matches. Meaning any @list base information is stored, but completely irretrievable--as they're now detached graphs. 😢

Looking for a fix...as I use lots of @lists.

[jmatsushita]

You're right, i pulled on that thread a little and realised that @list simply weren't implemented. i gave it a shot but it needs more work. Would you like to give it a try? I don't have a lot of time these days unfortunately.

…

On 15 Mar 2017 20:47, "BigBlueHat" ***@***.***> wrote: So @jmatsushita <https://github.com/jmatsushita> those aren't actually matching UUID's. They're each one character different...on both sides (subject/object) of the graphs...so *nothing* matches. Meaning any @list base information is stored, but completely irretrievable--as they're now detached graphs. 😢 Looking for a fix...as I use lots of @lists. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVvAQnAIAIV57WuhIag2e-CiQtJEJKnks5rmEBVgaJpZM4L64cY> .

[BigBlueHat]

Yeah. I've begun digging into it...but nothing to report yet. Any findings from your earlier digging?

I'm pretty sure the trouble is in fetchExpandedTriples: https://github.com/mcollina/levelgraph-jsonld/blob/master/index.js#L338

[BigBlueHat]

So. Here's what I heard back from the friendly folks in #jsonld on irc.freenode.net:

bigbluehat: Compaction won’t compact to @list from an expanded rdf:first/rdf:rest expression; for this you need to use the fromRdf algorithm. But, it still won’t in this case, as well formed lists that have an rdf:type other than rdf:List.
Playground doesn’t have a fromRdf tab (there’s a feature request for this). You can try RDF roundtriping from JSON-LD to JSON-LD at http://rdf.greggkellogg.net/distiller, though.

Given that, I'm working to get my head around all the stuff happening in fetchExpandedTriples...more soon, hopefully.

[jmatsushita]

Similar to what I've heard here json-ld/json-ld.org#465

You're right it is fetchExpandedTriples that's the crux of the matter, but in this case we need to maintain references to the triples that constitute the list unless we can find a way to create a levelgraph query which grabs all the list items and allows to build the list in one go.

[BigBlueHat]

@jmatsushita yeah... One crazy idea I've been pondering is actually turning the returned triples into application/n-quads and then passing that to jsonld.fromRDF--which (possibly) avoids much of the tangle that is fetchExpandedTriples.

Any thoughts on that hair brained scheme? 😸

[aredridel]

The biggest problem there is that you need framing to get the output into a shape you'd want to use as JSON, rather than as LD. fromRDF's output is very generic, and not centered on any particular root node.