Arbitrary JSON-LD for topics in API

[ptgolden]

How should we represent this in Topics' JSON-LD representations?

I'll start from this example topic:

{
   "@context": {
        "url": "@id"
    }
    "url": "http://workingnotes.org/projects/emma/topics/4/"
}

Let's say that someone wants to add a triple whose subject is this topic, predicate is http://example.org/v#color and object is the string literal "green".

The simplest way to do this would be to just extend the API's representation of the topic:

{
   "@context": {
        "url": "@id"
    }
    "url": "http://workingnotes.org/projects/emma/topics/4/",
    "http://example.org/v#color": "green"
}

However, I think it makes sense to fence extra properties (i.e. not ones built in to Editors' Notes) into their own namespace, with its own context. That might look something like this:

{
   "@context": {
        "url": "@id",
        "structuredData": "@graph"
    },
    "url": "http://workingnotes.org/projects/emma/topics/4/",
    "structuredData": {
        "@context": {
            "color": "http://example.org/v#color"
        },
        "@id": "http://workingnotes.org/projects/emma/topics/4/",
        "color": "green"
    }
}

In this case, we have to repeat @id to set a subject for the statements in the @graph. That results in the following nquad:

<http://workingnotes.org/projects/emma/topics/4/> <http://example.org/v#color> "green" <http://workingnotes.org/projects/emma/topics/4/> .

Is that nonsensical, defining an RDF object as the subject of its own named graph?

If json-ld/json-ld.org#246 were a reality, we could set structuredData in the @context to be @index rather than @graph, making it a semantically meaningless grouping. However, that's not possible with the current JSON-LD standard.

I still think this second approach makes the most sense, because it makes it clear which properties are user-defined and which are EN-defined. It would be nice to be able to say, in effect: "here's your own JSON-LD space to do whatever you want."

Any other ideas?

[rybesh]

Let's think about how we want to use named graphs. We can potentially give any arbitrary set of triples a URI so that it can be tracked more easily for provenance, versioning, access control, whatever. So, if I understood correctly, you are proposing that we create a named graph for each project topic, which would include all statements that constitute the structured data for the topic, outside of the administrative stuff we need to just make WN work. That makes sense to me. I don't think we want to use the same URI to identify the named graph as we use to identify the topic, though.

Would it perhaps make sense to have, rather than a named graph per project topic, a single named graph for all the structured data for all the project's topics? This would still give them their own "space". So, something like:

{
   "@context": {
        "url": "@id",
        "structuredData": "@graph"
    },
    "url": "http://workingnotes.org/projects/emma/data/",
    "structuredData": {
        "@context": {
            "color": "http://example.org/v#color"
        },
        "@id": "http://workingnotes.org/projects/emma/topics/4/",
        "color": "green"
    }
}

[rybesh]

:+1: on having separate named graphs for WN and the project.

[ptgolden]

Here's one way to get multiple named graphs. hmm.

[
    {
      "@context": {
        "name": "http://workingnotes.org/v#name"
      },
      "@id": "http://workingnotes.org/",
      "@graph": {
        "@id": "http://workingnotes.org/projects/emma/topics/4/",
        "name": "asdf"
      }
    },
    {
      "@context": {
        "color": "http://workingnotes.org/projects/emma/v#color"
      },
      "@id": "http://workingnotes.org/projects/emma",
      "@graph": {
        "@id": "http://workingnotes.org/projects/emma/topics/4/",
         "color": "green"
      }
    }
]

[rybesh]

That's not so bad…

[ptgolden]

And, keeping with our hydra definitions, the @type of the first graph's http://workingnotes.org/projects/emma/topics/4/ can be http://workingnotes.org/v#Topic (or wherever we put the site-wide vocabulary), and the second can be http://workingnotes.org/projects/emma/v#Topic. Each of these can have different hydra:supportedProperty values: site-wide attributes of topics for the former and project-specific ones for the latter.

Make sense?

But what do the payloads look like for PUTting topics shaped like this? How can we make them self-describing?

[ptgolden]

https://github.com/json-ld/json-ld.org/issues/398 would help with this too

[ptgolden]

Or maybe a topic should be split into two resources. A client would only be able to do HTTP operations on whichever one of the resources (project-specific or site-wide) that they were dealing with. We could have a "virtual" resource that combines the two in https://github.com/editorsnotes/editorsnotes/issues/291#issuecomment-187326161. These could then have some sort of owl part-whole relationship.

[ptgolden]

This is real deal stuff

[ptgolden]

Let's say that these two split resources are:

1. http://workingnotes.org/projects/emma/topics/1/wn

   and

2. http://workingnotes.org/projects/emma/topics/1/emma

   And the combination resource is:

3. http://workingnotes.org/projects/emma/topics/1/.

How should we express that (3) is the "combination" of (1) and (2)? A couple possibilities:

• owl:unionOf
• vaem:hasAspect

This isn't my comfort zone, so they may not make sense.

[ptgolden]

In the end, it might be something like:

Graph (1):

<http://workingnotes.org/projects/emma/topics/1/wn> <http://workingnotes.org/v#preferredName> "Alexander Berkman"

Graph (2):

<http://workingnotes.org/projects/emma/topics/1/emma> <http://workingnotes.org/emma/v#customProperty> "customValue"

Graph (3):

<http://workingnotes.org/projects/emma/topics/1/>
    owl:unionOf (
        <http://workingnotes.org/projects/emma/topics/1/wn>
        <http://workingnotes.org/projects/emma/topics/1/emma>
     );
    <http://workingnotes.org/v#preferredName> "Alexander Berkman";
    <http://workingnotes.org/emma/v#customProperty> "customValue".

Does that work?

[rybesh]

I think I prefer vaem:hasAspect (or maybe even vaem:hasDimension) to owl:unionOf, since the latter would imply that our topics are classes rather than instances. That VAEM vocabulary seems nice, how did you find it?

[rybesh]

And yes, other than the choice of term I like this way of modeling it.

[ptgolden]

I found it searching for "aspect" on http://lov.okfn.org.

OK, great! So then it would be:

<http://workingnotes.org/projects/emma/topics/1/>
    vaem:hasAspect
        <http://workingnotes.org/projects/emma/topics/1/wn>,
        <http://workingnotes.org/projects/emma/topics/1/emma>;
    <http://workingnotes.org/v#preferredName> "Alexander Berkman";
    <http://workingnotes.org/emma/v#customProperty> "customValue".

[ptgolden]

I think hasAspect is appropriate (as opposed to the less specific hasDimension)- it seems to fit our use case.