- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Sat, 5 Jun 2021 12:26:36 -0700
- To: Sean Kohler <skohler@unifiedcompliance.com>
- Cc: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>, "public-json-ld@w3.org" <public-json-ld@w3.org>
- Message-Id: <4AF4B2BE-5D9C-4466-A9CD-9DC3858B10CE@greggkellogg.net>
Sean, this does clarify your use case, but I really don’t think adding a keyword to JSON-LD is the way to go. You describe modifying the data representation of your models to provide a signal to transport-level layers, which isn’t how I’d do it, but is not uncommon in practice. But, it’s not a data-model issue, so wouldn’t have any relationship to JSON-LD itself. You might describe a vocabulary (along the line of schema.org <http://schema.org/> Actions) for these signals, and that has been a big focus of the aforementioned Hydra vocabulary, but as a keyword it doesn’t really make sense to me. If your goal is to just use a term that can be easily parsed as JSON, then there are certainly other special characters available to use.
Note that you can always define “@action” as a term expanding to an IRI; a processor should give you a warning for doing this, but will not drop such a property.
I think it would be worth looking at what the Hydra community has done, as they’ve spent quite some time on the role of provisioning API affordances using JSON-LD.
Gregg Kellogg
gregg@greggkellogg.net
> On Jun 4, 2021, at 3:57 PM, Sean Kohler <skohler@unifiedcompliance.com> wrote:
>
> Thanks for the responses, Pierre and Gregg. It is kind of you to provide what information you can.
>
> Perhaps it is more vocabulary related, but even that is likely a stretch now that you describe it. We are defining schema objects for compliance data and are writing REST APIs to work with the data. We wanted to use JSON-LD specifically as we believe it will provide better information in the API responses as to where and how data interacts. We are also rendering data into html and other "document" formats where we are attempting to embed the data objects. (we have been growing along the way, but I am certain we do not have it perfect yet)
>
> One challenge we are trying to overcome is in REST PATCH operations where we want to allow adding data objects (that exist on their own) into arrays.
>
> For a basic example, if we had a schema Thing called "House" (not the schema.org <http://schema.org/> definition) and a House happens to have an array of Thing "Person".
>
> {
> "@context": "mynewschema.org <http://mynewschema.org/>",
> "@type": "House",
> "@id": "https://myAPI.com/house/1 <https://myapi.com/house/1>",
> "record_id": 1,
> "address": "123 A Way",
> "people": [
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/1 <https://myapi.com/person/1>",
> "record_id": 1,
> "name": "Fred"
> },
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/2 <https://myapi.com/person/2>",
> "record_id": 2,
> "name": "Sally"
> }
> ]
> }
>
> With a REST GET at the API endpoint, you can get that object... and I "think" it doesn't break any JSON-LD model rules. (if it does, I am all ears heh) What we have been attempting to solve for is "object update" however. For our example, we can say Fred and Sally now have a kid named Bob.
>
> We considered a REST PUT. Bring the object local, pop a Bob on the array. PUT the object back. There are some reasons we cannot do this, however.
> We considered a REST PATCH. This is fine for changing the property "address". It might be fine if we replace the Person object array with a new array of three Person objects. There are some reasons we cannot do this, however. One mechanism we are considering to programatically push a Person onto the array (or remove one) in a PATCH operation is to provide a property that explicitly describes the "action" for the array manipulation.
>
> One of our developers thought perhaps this could be solved with something like this
>
> An @action property that describes what is possible in a PATCH operation when a GET operation is performed.
>
> {
> "@context": "mynewschema.org <http://mynewschema.org/>",
> "@type": "House",
> "@id": "https://myAPI.com/house/1 <https://myapi.com/house/1>",
> "record_id": 1,
> "address": "123 A Way",
> "people": [
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/1 <https://myapi.com/person/1>",
> "@action": "link|unlink",
> "record_id": 1,
> "name": "Fred"
> },
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/2 <https://myapi.com/person/2>",
> "@action": "link|unlink",
> "record_id": 2,
> "name": "Sally"
> }
> ]
> }
>
>
> So after Bob is created as Person number 3 on the Person endpoint (POST operation)... Send a PATCH operation to the House endpoint with...
>
> {
> "@context": "mynewschema.org <http://mynewschema.org/>",
> "@type": "House",
> "@id": "https://myAPI.com/house/1 <https://myapi.com/house/1>",
> "record_id": 1,
> "address": "123 A Way",
> "people": [
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/1 <https://myapi.com/person/1>",
> "@action": "link|unlink",
> "record_id": 1,
> "name": "Fred"
> },
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/2 <https://myapi.com/person/2>",
> "@action": "link|unlink",
> "record_id": 2,
> "name": "Sally"
> },
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/3 <https://myapi.com/person/3>",
> "@action": "link",
> "record_id": 3,
> "name": "Bob"
> }
> ]
> }
>
> And if Fred moves away (bad Fred) PATCH
>
> {
> "@context": "mynewschema.org <http://mynewschema.org/>",
> "@type": "House",
> "@id": "https://myAPI.com/house/1 <https://myapi.com/house/1>",
> "record_id": 1,
> "address": "123 A Way",
> "people": [
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/1 <https://myapi.com/person/1>",
> "@action": "unlink",
> "record_id": 1,
> "name": "Fred"
> },
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/2 <https://myapi.com/person/2>",
> "@action": "link|unlink",
> "record_id": 2,
> "name": "Sally"
> },
> {
> "@type": "Person",
> "@id": "https://myAPI.com/person/3 <https://myapi.com/person/3>",
> "@action": "link",
> "record_id": 3,
> "name": "Bob"
> }
> ]
> }
>
> It is pretty creative and seems like a decent way forward given some of our constraints. And then we discovered another issue. Our Person object doesn't have an "@action" property. None of our Things do. The object will not validate without adding "@action" to every defined Thing. It is then we realized that we do not have to define any of the language keywords in ALL of our objects. It appears a JSON-LD validator would allow language keywords!
>
> Hence the question... :)
>
> The gist is - we are trying to use a property as a programmatic variable without having to define that property in every Thing in the schema - and still be able to pass validation. I understand this is adjacent to the purpose of JSON-LD / RDF, and it is great that a JSON-LD processor would ignore unknown keywords... I am not sure the same can be said of a JSON-LD validator?
>
> Any advice, guidance, grumblings, and/or general discontent is greatly appreciated!
>
> Cheers,
>
> Sean Kohler, CTO
> p. 702.805.2467
> Unified Compliance
> www.unifiedcompliance.com <http://www.unifiedcompliance.com/>
>
> "My computer once beat me at chess, but it was no match for me at kick-boxing." -Emo Phillips
>
>
>
> From: Gregg Kellogg <gregg@greggkellogg.net>
> Sent: Friday, June 4, 2021 12:16 PM
> To: Sean Kohler <skohler@unifiedcompliance.com>
> Cc: public-json-ld@w3.org <public-json-ld@w3.org>
> Subject: Re: New JSON-LD keyword
>
>> On Jun 2, 2021, at 3:07 PM, Sean Kohler <skohler@unifiedcompliance.com <mailto:skohler@unifiedcompliance.com>> wrote:
>>
>> We have a challenge we are trying to overcome in an API leveraging JSON-LD objects. We think having a language keyword would help us overcome this challenge.
>>
>> "@action" : "link|unlink"
>>
>> Is this something we could discuss as to how and why?
>
> This sounds something that would be more vocabulary related, rather than keyword. Keywords are used to convey information to help describe the JSON using the RDF data model, and link/unlink is not part of a data model. It might be used as part of a predicate description, perhaps from the Hydra vocabulary for describing APIs [1], or as a link relationship as defined in RFC5988 [2]. But, it really seems closer to the proposed (and expired) HTTP LInk and Unlink Methods [3]. In any case, I don’t see how that would be part of the JSON-LD data model.
>
> As Pierre-Antoine suggested, maybe you could describe your use case further.
>
> Gregg
>
> [1] https://www.hydra-cg.com/spec/latest/core/ <https://www.hydra-cg.com/spec/latest/core/>
> [2] https://datatracker.ietf.org/doc/html/rfc5988 <https://datatracker.ietf.org/doc/html/rfc5988>
> [3] https://datatracker.ietf.org/doc/html/rfc5988 <https://datatracker.ietf.org/doc/html/rfc5988>
>
>
>> Sean Kohler, CTO
>> p. 702.805.2467
>> Unified Compliance
>> www.unifiedcompliance.com <http://www.unifiedcompliance.com/>
>>
>> "My computer once beat me at chess, but it was no match for me at kick-boxing." -Emo Phillips
Received on Saturday, 5 June 2021 19:27:27 UTC