Alternative to framing flags

[gkellogg]

During discussions on Framing and Query some use cases were shown where a greater amount of query capability would be useful than that available through the (current) framing algorithm. Dave Longley pointed to GraphQL as being a useful paradigm, which is in realy use in APIs. I (@gkellogg) pointed out that, as the JSON-LD data model is RDF, SPARQL is a natural query language, perhaps with a JSON syntax.

Ultimately, the discussion converged on completing the existing framing model, and possibly looking into more powerful query at a later date in a separate specificaiton.

One consideration from this is that the framing syntax could, perhaps, be better described using structures that could be more congruent with query models. For example, consider the framing keywords:

• @embed – determines how/if nodes are embedded as property values, or referenced.
• @explicit – determines if only those properties contained in the frame are used in output, or if all properties are used.
• @omitDefault – Causes default values to be ignored.
• @requireAll – Requires all properties in frame to be present in node for match.

Embedding can be inferred by the frame using an embedded node syntax, in which case the framed result would be included. For examples:

{
  "@context": {},
  "@type": "Library",
  "contains": {
    "@id": {}
  }
}

Would determine both that values of "contains" must be a node, and that those values be embedded.

For explicit output, adding a wildcard property values would be consistent with a SPARQL pattern such as the following:

?subj ?pred ?obj

Which would match on any property. A frame such as the following would include properties not specified within the frame explicitly:

{
  "@context": {},
  "@type": "Library",
  "contains": {"@id": {}},
  "@any": {}
}

Omit default does not seem too useful, since the frame author can simply not include default values.

The @requireAll flag might be better used with explicit optional output, which would be more consistent with the SPARQL OPTIONAL mechanism (left join). For example:

{
  "@context": {},
  "@type": "Library",
  "dc:title": {"@optional": {}},
  "contains": {"@id": {}}
}

Might indiciate that dc:title is not necessary for frame matching, but included in output if it exists; this could also include other sub-patterns, which may prevent things matching (for instance, if the @language doesn't match). This roughly would be equivalent to the following SPARQL:

WHERE {
  ?lib a :Library;
  :contains a ?book .
  OPTIONAL {
    ?lib dc:title ?title
  }
}

Groups of properties could be included together in an @optional block at the node level:

{
  "@context": {},
  "@type": "Library",
  "contains": {"@id": {}},
  "@optional": {
    "dc:title": {},
    "dc:description": {}
  }
}

This would match on Libraries without dc:title or dc:description, or on Libraries having both dc:title and dc:description. Of course, @optional might be multi-valued, to allow mutliple OPTIONAL blocks.

These changes in frame syntax remove the use of framing flags in favor of constructs that more closely relate to potential query structures, which might, for example, include the use of explicit variables.

[Fak3]

I tried to learn what is framing about and I didn't understand how it can be used to do
queries and even don't see a possible way to turn it into convenient query language.

I made an attempt to prototype how i see ideal query lang from pov of mortal web developer.
Yet I have no idea on the implementation details, or if it is possible at all.

'@context': {
    'fl': 'http://filter_lang.org/vocab',
    'ql': 'http://query_lang.org/vocab',
    ...
}
# List Query returns list of instances of given ql:root_class
'ql:list_query': {
    'ql:root_class': 'lib:Library'

    # Filtering is done on class basis
    'ql:filter': {
        'lib:Library': {
            'lib:has_book': {
                  'fl:property': 'dc:title',
                  'fl:exact_match': 'Ulysses'
            }
            # Same as
            # 'lib:has_book': {'dc:title': 'Ulysses'},

            'lib:has_book': {
                'lib:has_author': {
                    'fl:property': 'foaf:last_name',
                    'fl:startswith': 'Joyc'
                }
            }
        },
        'lib:Book': {
            'lib:publish_date': {
                'fl:year_match': 2016
            }
        }
    }
    'ql:layout': {
        'lib:Library': {
            'ql:properties': ['lib:name',  'geo:location']
            'ql:list_related': {
                'books': 'lib:has_book'
            }
        }
        'lib:Book': {
            'ql:properties': ['dc:title', 'lib:publish_date']
            'ql:list_related': {
                'authors': 'lib:has_author'
            }
        }
        'lib:Author' {
            'ql:properties': ['foaf:last_name']
        }
    }
}

And I would expect the query results to look like this:

[
    {
        'lib:name': 'National Library',
        'geo:location' {'geo:lat': 141, 'geo:lon': 6345}
        'books': [
            {
                'dc:title': 'Some 2016 book',
                'lib:publish_date': '2016-10-01'
                'authors': [
                    {'foaf:last_name': 'Robson'},
                    {'foaf:last_name': 'Davidson'}
                ]
            },
        ]
    },
    ...
]

[gkellogg]

Hi @Fak3, that is certainly one way that a query language would work. My syntax was based on the original framing spec, which operates on a "query-by-example" basis, where the frame looks like the shape of the document you want to create. Framing can be used as a poor man's query by adding objects in the frame that match a subset of the objects in the original document.

The proposal above attempts to make some small modifications to the framing syntax without fundamentally changing the program-by-example nature of the frame.

Your proposal seems to be a JSON query language that is fairly divorced from the layout syntax of existing framing. It may be that a full JSON query mechanism will need this type of expressivity, but that would be the topic of a different thread, and something likely beyond a 1.1 timeframe (IMHO).

[niklasl]

Perhaps it is a complication that apart from framing data as a tree, the framing algorithm also handles filtering and selection of properties? In most cases I've encountered, the need for framing has only been about structuring an already selected set of data into a convenient tree. In the applications I've worked with, I've gone a slightly different route.

Firstly, the filtering/selection is performed, either using SPARQL to get the triples of interest, or relying on custom code to just pick out the pieces required. In these cases, it is ideal to have a specification of which properties are of interest for a specific class (or base class), and which "chips" to include for linked items (such as names of related agents, or labels/notations of concepts and their schemes). Framing does provide this aspect too, but I wonder if that could be done independently.

After selection of relevant properties for related resources, I use a rather simple auto-framing algorithm. It just takes an @id, selects the node having that @id as the root and frames everything beneath that (also taking @reverse into account in order to capture relevant incoming links). (See https://github.com/libris/lxltools/blob/0.4.2/lxltools/ld/frame.py and tests at https://github.com/libris/lxltools/tree/0.4.2/test (this is borrowed from and will eventually reintegrate into https://github.com/RDFLib/rdflib-jsonld/tree/feature/autoframe). Also, see this related discussion: https://groups.google.com/forum/#!topic/rdflib-dev/U9Czox7kQL0)

This is configuration free, and does put limits on (at least) how multiple embedding of the same resource is done (it either just copies it multiple times or embeds the "first" occurrence). I really wonder if this approach still fulfils a lot of common framing needs though. It seems to cover the basics?

The takeaway is that framing could be quite simple (and ideally automatic, i.e. configuration-free) if the process of selecting what to include is done beforehand. If there is interest in this approach, I'll strive to get some time in order to help properly specify it.

[gkellogg]

The ship has sailed on this, closing.