- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 4 May 2020 10:39:48 -0700
- To: James Hudson <jameshudson3010@gmail.com>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Linked JSON <public-linked-json@w3.org>
- Message-Id: <1E2C51EB-EA6C-4D4D-BE4D-0DDE75011517@greggkellogg.net>
> On May 4, 2020, at 6:36 AM, James Hudson <jameshudson3010@gmail.com> wrote:
>
> Hello Gregg,
>
> This framing concept is still confusing. I am going to express my current understanding given https://tinyurl.com/y8jmu3ew <https://tinyurl.com/y8jmu3ew>. If there is a better place to have this conversation, please let me know.
>
> Switching to the visualized tab, I see:
>
> _####1 ----> yyyy ----> _####2 ----> name: my name
>
> If I am correct, there are two frames defined by the input:
>
> {
> "@context": {
> ...
> },
> "yyyy": {
> "name": "my name"
> }
> }
>
> and
>
> "yyyy": {
> "name": "my name"
> }
>
> These would correspond to the two blank nodes in the visualized graph _####1 ----> and _####2 ---->
>
> Is this correct?
On the left, is the input document, which defines two node objects, the first contains the single property “yyyy”, which references the second node object containing the single property “name”.
On the right is the frame document, which is used to construct the output by matching against the input document. It looks for all nodes that match the outer frame (containing `@type` and “yyyy”, followed by the inner frame, containing just `@type`.
> When you say that the outer frame is matching on both node objects, what are the two node objects? Are they the two blank nodes in the visualized graph?
The semantics of frame matching are that a node object matching _any_ of the properties in the frame matches. Because it contains two properties `@type` and “yyyy”, by default, it will match all nodes, as `@type` has a default value, so matches every node object. By using the `@requireAll` property, you change the matching semantics to require _all_ listed properties, not _any_, so it will only match nodes that contain the “yyyy” property.
> I would now like to consider a more complex example that would better match my real use case.
>
> Let's say that my JSON-LD input looked like:
>
> ( https://tinyurl.com/y78j5a69 <https://tinyurl.com/y78j5a69> )
>
> {
> "@context": {
> "ex": "http://example.com/ <http://example.com/>",
> "yyyy": "ex:yyyy",
> "xxxx": "ex:xxxx",
> "name": "ex:name"
> },
> "yyyy": {
> "name": "my name YYYY"
> }
> }
>
> with a frame:
>
> {
> "@context": {
> "ex": "http://example.com/ <http://example.com/>",
> "yyyy": "ex:yyyy",
> "xxxx": "ex:xxxx",
> "name": "ex:name"
> },
> "@requireAll": true,
> "@type": {
> "@default": "ex:MyType"
> },
> "yyyy": {
> "@type": {
> "@default": "ex:YYYY"
> }
> },
> "xxxx": {
> "@type": {
> "@default": "ex:XXXX"
> }
> }
> }
>
> The resulting output is:
>
> {
> "@context": {
> "ex": "http://example.com/ <http://example.com/>",
> "yyyy": "ex:yyyy",
> "xxxx": "ex:xxxx",
> "name": "ex:name"
> }
> }
>
> The idea I am trying to express is that my JSON-LD input may or may not have
>
> "xxxx": {
> "name": "my name XXXX"
> }
>
> because is is not a required input key. If it does exist in the input, then it should be assigned the type ex:XXXX. If I have "@requireAll": true, "xxxx" becomes required, which is not desirable. If I leave out "@requireAll": true, I get undesirable matches leading to unwanted output.
>
> Can the framing feature handle this case?
Yes, you need to use `@default in this case, which will provide the default value if none exists. That would be the following frame (https://tinyurl.com/ycpsyf87 <https://tinyurl.com/ycpsyf87>):
{
"@context": {
"ex": "http://example.com/",
"yyyy": "ex:yyyy",
"xxxx": "ex:xxxx",
"name": "ex:name"
},
"@requireAll": true,
"@type": {
"@default": "ex:MyType"
},
"yyyy": {
"@type": {
"@default": "ex:YYYY"
}
},
"xxxx": {
"@default": {
"@type": "ex:XXXX"
}
}
}
Note that the default value for “xxxx” is a node object containing a specific value for `@type`.
The basic idea when framing is to descend through the frame document, and match against all nodes that fit that specific frame, for which you can use things like `@requireAll` and `@explicit` as well as various wildcards to control matching further (e.g., `”@type”: {}` to match any time, or `”@type”: []` to match on no type. The Framing spec has various examples to lay out features you can use for matching, controlling testing, and providing default values.
Hope that helps,
Gregg
> I think I would be able to manage this with a SPARQL query which modified the graph, but I would prefer to use something declarative like Framing.
>
> Regards,
> James
>
>
>
> On Fri, May 1, 2020 at 5:16 PM Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
>> On May 1, 2020, at 12:59 PM, James Hudson <jameshudson3010@gmail.com <mailto:jameshudson3010@gmail.com>> wrote:
>>
>> Hello Gregg,
>>
>> Thank you for your reply and your willingness to answer the quick question on IRC earlier today.
>>
>> Pointing me to the test case and the specific example was quite useful (especially the test case).
>>
>> There is still something I am missing, however.
>>
>> Let's say I start with the following json:
>>
>> {
>> "@context": {
>> "ex": "http://example.com/ <http://example.com/>",
>> "yyyy": "ex:yyyy",
>> "name": "ex:name"
>> },
>> "yyyy": {
>> "name": "my name"
>> }
>> }
>>
>> and use the following frame:
>>
>> {
>> "@context": {
>> "ex": "http://example.com/ <http://example.com/>",
>> "yyyy": "ex:yyyy",
>> "name": "ex:name"
>> },
>>
>> "@type": {
>> "@default": "ex:MyType"
>> },
>>
>> "yyyy": {
>> "@type": {
>> "@default": "ex:XXXX"
>> }
>> }
>> }
>>
>> This results in the following new graph:
>>
>> {
>> "@context": {
>> "ex": "http://example.com/ <http://example.com/>",
>> "yyyy": "ex:yyyy",
>> "name": "ex:name"
>> },
>> "@graph": [
>> {
>> "@type": "ex:MyType",
>> "yyyy": {
>> "@id": "_:b1",
>> "@type": "ex:XXXX",
>> "name": "my name"
>> }
>> },
>> {
>> "@id": "_:b1",
>> "@type": "ex:MyType",
>> "name": "my name",
>> "yyyy": null
>> }
>> ]
>> }
>>
>> I am not sure where:
>>
>> {
>> "@id": "_:b1",
>> "@type": "ex:MyType",
>> "name": "my name",
>> "yyyy": null
>> }
>>
>> came from.
>>
>> It is close to what I would like to see as the final result which is:
>>
>> {
>> "@context": {
>> "ex": "http://example.com/ <http://example.com/>",
>> "yyyy": "ex:yyyy",
>> "name": "ex:name"
>> },
>> "@type": "ex:MyType",
>> "yyyy": {
>> "@type": "ex:XXXX",
>> "name": "my name"
>> }
>> }
>
> That’s because the outer frame is matching on both node objects, given the presense of both `@type` and `yyyy`, it will match if _either_ is present. You can restrict this using `@requireAll`, as evidenced by the following playground link: https://tinyurl.com/y8jmu3ew <https://tinyurl.com/y8jmu3ew>
>
> {
> "@context": {
> "ex": "http://example.com/ <http://example.com/>",
> "yyyy": "ex:yyyy",
> "name": "ex:name"
> },
> "@requireAll": true,
> "@type": {
> "@default": "ex:MyType"
> },
> "yyyy": {
> "@type": {
> "@default": "ex:XXXX"
> }
> }
> }
>
>> Playground Link:
>>
>> https://json-ld.org/playground/#startTab=tab-framed&json-ld=%7B%22%40context%22%3A%7B%22ex%22%3A%22http%3A%2F%2Fexample.com%2F%22%2C%22yyyy%22%3A%22ex%3Ayyyy%22%2C%22name%22%3A%22ex%3Aname%22%7D%2C%22yyyy%22%3A%7B%22name%22%3A%22my%20name%22%7D%7D&frame=%7B%22%40context%22%3A%7B%22ex%22%3A%22http%3A%2F%2Fexample.com%2F%22%2C%22yyyy%22%3A%22ex%3Ayyyy%22%2C%22name%22%3A%22ex%3Aname%22%7D%2C%22%40type%22%3A%7B%22%40default%22%3A%22ex%3AMyType%22%7D%2C%22yyyy%22%3A%7B%22%40type%22%3A%7B%22%40default%22%3A%22ex%3AXXXX%22%7D%7D%7D&context=%7B%7D <https://json-ld.org/playground/#startTab=tab-framed&json-ld=%7B%22%40context%22%3A%7B%22ex%22%3A%22http%3A%2F%2Fexample.com%2F%22%2C%22yyyy%22%3A%22ex%3Ayyyy%22%2C%22name%22%3A%22ex%3Aname%22%7D%2C%22yyyy%22%3A%7B%22name%22%3A%22my%20name%22%7D%7D&frame=%7B%22%40context%22%3A%7B%22ex%22%3A%22http%3A%2F%2Fexample.com%2F%22%2C%22yyyy%22%3A%22ex%3Ayyyy%22%2C%22name%22%3A%22ex%3Aname%22%7D%2C%22%40type%22%3A%7B%22%40default%22%3A%22ex%3AMyType%22%7D%2C%22yyyy%22%3A%7B%22%40type%22%3A%7B%22%40default%22%3A%22ex%3AXXXX%22%7D%7D%7D&context=%7B%7D>
>>
>> Regards,
>> James
>>
>> On Fri, May 1, 2020 at 2:51 PM Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
>> There’s also an example in the framing spec: https://w3c.github.io/json-ld-framing/#sample-library-frame-with-default-type <https://w3c.github.io/json-ld-framing/#sample-library-frame-with-default-type>
>>
>> Gregg Kellogg
>>
>> Sent from my iPad
>>
>>> On May 1, 2020, at 11:42 AM, James Hudson <jameshudson3010@gmail.com <mailto:jameshudson3010@gmail.com>> wrote:
>>>
>>>
>>> Hello Robert,
>>>
>>> Thank you for confirming what I suspected.
>>>
>>> However, as I understand it, doing this is possible using https://www.w3.org/TR/json-ld11-framing <https://www.w3.org/TR/json-ld11-framing>
>>>
>>> But, it is unclear what my frame should look like.
>>>
>>> Ideally, I would like to be able to start with:
>>>
>>> {
>>> "@context": {
>>> "ex": "http://example.com/ <http://example.com/>",
>>> "yyyy": "ex:yyyy",
>>> "name": "ex:name",
>>> "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>",
>>> "rdfs": "http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema#>",
>>> "sch": "http://schema.org/ <http://schema.org/>",
>>> "xml": "http://www.w3.org/XML/1998/namespace <http://www.w3.org/XML/1998/namespace>",
>>> "xsd": "http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#>"
>>> },
>>> "yyyy": {
>>> "name": "my name"
>>> }
>>> }
>>>
>>> and end up with the desired result. I just need two "@types" inserted in this simple example.
>>>
>>> If anyone can provide any assistance, it would be appreciated as I continue to read about framing.
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Fri, May 1, 2020 at 1:14 PM Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>> wrote:
>>>
>>>
>>> Hi James,
>>>
>>> You are not missing anything, that's not possible using JSON-LD.
>>>
>>> There have been several requests for this sort of functionality, but it falls out of scope as it creates new data or transforms data, which is out of scope of the functionality of a context document.
>>> For example, these issues were rejected for this reason:
>>> https://github.com/w3c/json-ld-syntax/issues?q=+is%3Aissue+label%3A%22out+of+scope%3A+transformation%22+ <https://github.com/w3c/json-ld-syntax/issues?q=+is%3Aissue+label%3A%22out+of+scope%3A+transformation%22+>
>>>
>>> Rob
>>>
>>>
>>> On Fri, May 1, 2020 at 6:58 AM James Hudson <jameshudson3010@gmail.com <mailto:jameshudson3010@gmail.com>> wrote:
>>> Hello,
>>>
>>> Either this is not possible or I am missing something obvious. I am not sure which.
>>>
>>> I have the following json-ld document:
>>>
>>> {
>>> "@id": "ex:Bobe",
>>> "@type": "ex:MyType",
>>> "@context": {
>>> "ex": "http://example.com/ <http://example.com/>",
>>> "yyyy": "ex:yyyy",
>>> "name": "ex:name",
>>> "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>",
>>> "rdfs": "http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema#>",
>>> "sch": "http://schema.org/ <http://schema.org/>",
>>> "xml": "http://www.w3.org/XML/1998/namespace <http://www.w3.org/XML/1998/namespace>",
>>> "xsd": "http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#>"
>>> },
>>> "yyyy": {
>>> "@type": "ex:XXXX",
>>> "name": "my name"
>>> }
>>> }
>>>
>>> which has the following RDF representation:
>>> ( using https://github.com/RDFLib/rdflib <https://github.com/RDFLib/rdflib> )
>>>
>>> @prefix ex: <http://example.com/ <http://example.com/>> .
>>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema#>> .
>>> @prefix sch: <http://schema.org/ <http://schema.org/>> .
>>> @prefix xml: <http://www.w3.org/XML/1998/namespace <http://www.w3.org/XML/1998/namespace>> .
>>> @prefix xsd: <http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#>> .
>>>
>>> ex:Bobe a ex:MyType ;
>>> ex:yyyy [ a ex:XXXX ;
>>> ex:name "my name" ] .
>>>
>>> What I would like to be able to do is write "yyyy": { ... } as
>>>
>>> "yyyy": {
>>> "name": "my name"
>>> }
>>>
>>> and have "@type": "ex:XXXX" specified in the "@context".
>>>
>>> Is this possible?
>>>
>>> What I have tried:
>>>
>>> {
>>> "@id": "ex:Bobe",
>>> "@type": "ex:MyType",
>>> "@context": {
>>> "ex": "http://example.com/ <http://example.com/>",
>>> "yyyy": {
>>> "@id": "ex:yyyy",
>>> "@type": "ex:XXXX"
>>> },
>>> "name": "ex:name",
>>> "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>",
>>> "rdfs": "http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema#>",
>>> "sch": "http://schema.org/ <http://schema.org/>",
>>> "xml": "http://www.w3.org/XML/1998/namespace <http://www.w3.org/XML/1998/namespace>",
>>> "xsd": "http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#>"
>>> },
>>> "yyyy": {
>>> "name": "my name"
>>> }
>>> }
>>>
>>> which has the following RDF representation:
>>> ( using https://github.com/RDFLib/rdflib <https://github.com/RDFLib/rdflib> )
>>>
>>> @prefix ex: <http://example.com/ <http://example.com/>> . a
>>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema#>> .
>>> @prefix sch: <http://schema.org/ <http://schema.org/>> .
>>> @prefix xml: <http://www.w3.org/XML/1998/namespace <http://www.w3.org/XML/1998/namespace>> .
>>> @prefix xsd: <http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#>> .
>>>
>>> ex:Bobe a ex:MyType ;
>>> ex:yyyy [ ex:name "my name" ] .
>>>
>>> The N-Quad representation on the JSON-LD Playground is:
>>>
>>> <http://example.com/Bobe <http://example.com/Bobe>> <http://example.com/yyyy <http://example.com/yyyy>> _:b0 .
>>> <http://example.com/Bobe <http://example.com/Bobe>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://example.com/MyType <http://example.com/MyType>> .
>>> _:b0 <http://example.com/name <http://example.com/name>> "my name" .
>>>
>>>
>>> The "@type" information is lost.
>>>
>>> Regards,
>>> James
>>>
>>>
>>>
>>>
>>> --
>>> Rob Sanderson
>>> Semantic Architect
>>> The Getty Trust
>>> Los Angeles, CA 90049
>
Received on Monday, 4 May 2020 17:40:07 UTC