Converting to JSON-LD from JSON

Question

I am working on a project which requires us to use an existing service which speaks json-ld. We speak json. I am still working through the http://www.w3.org/TR/json-ld/ documentation as well as juggling HOW to convert json > json-ld(and back).

Some questions.. If I supply 2 context's like this..

"@context": [
        "http://example/test1/core.jsonld",
        "http://example2/test2/core.jsonld"
    ],

How do the key's know which prefix to apply? for example

(test1 or test2)name : ..
(test1 or test2)date : ..
(test1 or test2)address : ..

So far to my understanding of how this works, is that any json can be converted to json ld. We need to supply it a context, so it knows the 'iri' or namespace.

Also, the current example json-ld I am working with also has some key's with no prefix defined, so I imagine there is a default, but there is nothing that shows me what the default is(no @vocab, literally just the two context defined). I imagine the default would be a context, but in this case I have 2.

Correct me if I am wrong but all json can be converted to json-ld and vice versa? I am looking for Java solutions ATM.

a really basic example of what I want

{
    "id": 1,
    "name": "A green door",
    "price": 12.50,
}

to be

{
    @context{
     test : www.example.com/test/core.json-ld
     test2 : www.example.com/test2/core.json-ld
     }
    "id": 1,
    "test:name": "A green door",
    "test2:price": 12.50,
}

edit: so here is an example of what the service expects from me

{
    "@context": [
        "http://test.net/abcd/contexts/core.jsonld",
        "http://test.net/abcd/contexts/def/4.0/core.jsonld"
    ],

    "startDate": { "@value": "2009-11-21T22:17:10Z", "@type": "xsd:dateTime" },
    "endDate": { "@value": "2005-13-24T22:01:01Z", "@type": "xsd:dateTime" },
    "comment": "my comment",
    "example": [{
      "properties": {
        "name": "test name",
        "description": "test description",
        "geometry": { "objVal": "POINT (127.25 3.243)", "confidence": "abcd-c:MED" },
        "def:width": { "decimalVal" : 50, "units": "abcd-u:meters" },
        "def:length": { "decimalVal" : 75, "units": "abcd-u:meters" },
        "def:height": { "decimalVal" : 200, "units": "abcd-u:meters" },
        "def:status": "operational",
        "def:typeCode": "building"
      },
      "metadata": {
        "@id": "object/123-32132-12321f",
        "type": [ "def:Building" ],
        "def:confidence": { "@id": "abcd-c:HIGH" },
        "def:typeCode": "building"
      }
    }],
    "def:classification": "classified",
    "def:confidence": { "@id": "abcd-c:HIGH" },
    "def:indicator": { "@value": "true", "@type": "xsd:boolean" },
    "def:levelCode": { "@id": "def-cl:FULL" },
    "source": {
      "@id": "remote-store/12321fd-cdsf143221",
      "mediaType": "image/jpeg",
      "startDate": { "@value": "2001-11-11T12:02:02Z", "@type": "xsd:dateTime" },
      "def:classification": "classified",
      "def:producer": "ABC",
      "name": "another name",
      "describedby": "source/123123123-f21321f" 
    }
}

my current json of course does not look like this, I can structure it similar but I feel it would be too easy if all I had to do was simply add the @context to my current json and pass it to the service, since it shows me what it expects. It sounds like I might be able to do just that though, and have the service that exists read the json with the annotation as being the same as the example json-ld I provided

Answer 1

First of all, every JSON-LD document is, by definition, also a valid JSON document.

How do the key's know which prefix to apply?

The contexts are evaluated in order. This means that term definitions in test2/core.jsonld in your example would overwrite the definitions in test1/core.jsonld. This is described in more detail in the JSON-LD spec in the section "Advanced Context Usage".

So far to my understanding of how this works, is that any json can be converted to json ld. We need to supply it a context, so it knows the 'iri' or namespace.

For most documents that's correct. There are a few forms which can't be mapped to sensible JSON-LD by just adding a context.

Also, the current example json-ld I am working with also has some key's with no prefix defined, so I imagine there is a default, but there is nothing that shows me what the default is(no @vocab, literally just the two context defined). I imagine the default would be a context, but in this case I have 2.

The easiest way to figure out what happens under the hood is to use the JSON-LD playground and expand the document. This gets rid of the context and shows how the processor interprets the data. Terms that aren't mapped to a IRI are ignored (i.e., dropped) when expanding the document.

Edit:

my current json of course does not look like this, I can structure it similar but I feel it would be too easy if all I had to do was simply add the @context to my current json and pass it to the service, since it shows me what it expects.

That would indeed be the easiest solution.

I am still confused on how the actual conversion from json to ld happens.

JSON-LD is also just JSON. So no magic there.. the simplest thing to do, if you can, is to just bring it into the form the other service expects.

I am hoping there is some type of library where i just supply it my json and give it a context and it does the conversion for me? is something like this available/possible? My use case is.... I create a json object from the ui, I send this json to my rest service which calls a service, in this service I want to convert it to json ld before calling another service which only understands ld.

That's possible as well but probably more complicated. You would need to call a JSON-LD processor's compact method with the expandContext option set to a context which maps your keys to the right IRIs and the context parameter set to the context(s) the other service expects. If the other service really uses JSON-LD, compacting it to use the same context shouldn't be necessary. Just expanding it by passing expandContext should be enough.

Lets say the pre-existing service supplies me their context for example www.test.com, what else needs to be done/supplied?

Nothing I guess