Feature/query syntax to force namespace expansion in query results

[aaj3f]

Description

A default context for a ledger will, by default, namespace query results according to that default context. So if "schema": "http://schema.org/ is part of the default context, and a query is issued that returns results with properties/values within the http://schema.org/ namespace, those properties/values will be namespaced as schema:... by default.

There should be an option expressed as query syntax for flagging a desire to return results without any default namespacing from the default context.

An example of this can be described by the following ledger & txns & queries:

If my ledger's default context looks like

    "context": {
        "schema": "http://schema.org/",
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "f": "https://ns.flur.ee/ledger#"
    }

And if I issue a commit like

{
        "@id": "ex:Andrew",
        "@type": [
            "schema:Person"
        ],
        "schema:name": "Andrew"
    }

A query such as this...

{
        "where": [ ["?i", "id", "ex:Andrew"] ],
        "select": { "?i": ["*"] }
    }

...returns this:

[
    {
        "id": "ex:Andrew",
        "rdf:type": [
            "schema:Person"
        ],
        "schema:name": "Andrew"
    }
]

There is a use case for wanting to not perform all default namespace shortening and to instead return query results in an expanded form regardless of default context, e.g. a query like...

{
        "where": [ ["?i", "id", "ex:Andrew"] ],
        "select": { "?i": ["*"] },
        "opts": {
           "expand": true
        }
    }

...and results like...

[
    {
        "id": "http://example.org/Andrew",
        "http://www.w3.org/1999/02/22-rdf-syntax-ns#type": [
            "http://schema.org/Person"
        ],
        "http://schema.org/name": "Andrew"
    }
]

Acceptance Criteria

• Query syntax exists such that query results for a particular query can be set to return in expanded form regardless of default contexts

Implementation Details

[dpetran]

The json-ld spec mentions "clearing" the context by setting it to null during the discussion of @protected:

https://www.w3.org/TR/json-ld11/#protected-term-definitions

[dpetran]

Is the idea that when a user requests expansion we return fully expanded json-ld? Should the "id" key be expanded to its natural "@id" form?

[dpetran]

Actually, is the intent to have a fully expanded query response?

[
    {
        "@id": "http://example.org/Andrew",
        "http://www.w3.org/1999/02/22-rdf-syntax-ns#type": [
            { "@value": "http://schema.org/Person" }
        ],
        "http://schema.org/name": [ {"@value": "Andrew" } ]
    }
]

Or some sort of hybrid expansion? If it's a hybrid, what things do we want expanded and which do we want to leave in compact form?

[bplatz]

Is the idea that when a user requests expansion we return fully expanded json-ld? Should the "id" key be expanded to its natural "@id" form?

There should be no "expanding" necessary - Fluree stores everything fully expanded, it is really you are just not "compacting" anything. So unless someone requested @id be compacted to id, then it shouldn't be touched.

[bplatz]

Actually, is the intent to have a fully expanded query response?

[
    {
        "@id": "http://example.org/Andrew",
        "http://www.w3.org/1999/02/22-rdf-syntax-ns#type": [
            { "@value": "http://schema.org/Person" }
        ],
        "http://schema.org/name": [ {"@value": "Andrew" } ]
    }
]

Or some sort of hybrid expansion? If it's a hybrid, what things do we want expanded and which do we want to leave in compact form?

Your example is expanded, can you be specific about what you mean? An error in your example is rdf:type is always an IRI - so it should not use @value, which in this case would be interpreted as a string. You can just output the string itself, as RDF already says this is an IRI... or instead use @id - either would be fine and both would still be 'expanded'.

Basically what we should do here is simply not 'compact' anything, as there is no context to compact with. Everything else should return as it does today.

I think we should add an option to always return datatypes, which we don't today, but that would be a different ticket.

[dpetran]

Good eye on the rdf:type error. I was providing the expanded example to contrast with the expanded example in the acceptance criteria, which still features the compacted "id" identifier and lacks the "@value" wrapping. If the ticket is meant to return fully expanded json-ld, that's good, as that's what I had been assuming before I returned to this ticket to read it more carefully.

Also, should we translate the type iri to "@type"? I don't think our expand or the official one do that, but I thought they were equivalent.

[bplatz]

Also, should we translate the type iri to "@type"? I don't think our expand or the official one do that, but I thought they were equivalent.

There is no type in JSON-LD, only @type. While many examples use just type, it is because it is compacted based on someone supplying that in a context.

Likewise, Fluree only uses type if a context has mapped @type to type... in your use case there is not context (it is blanked out), so Fluree should already be returning @type. If it isn't, that is a different bug and should be on a different ticket. I could believe this bug exists because we also alias rdf:type (in its expanded form) and a to @type... and if that aliasing was done in a not ideal way it is possible one of those other options gets spit out.

[dpetran]

I've got context clearing with nil working, it was a simple change. However, there's an additional wrinkle:

When we assemble query results, we don't build them as fully expanded json-ld, we build and compact each property as we process the select. Most notably, we don't wrap objects in @value or @id maps.

;; fully expanded json-ld
[{"@id" "http://example.com/dan",
   "http://example.com/x" [{"@value" 1}],
   "http://example.com/y" [{"@value" "y"}]}]

;; what we currently return
 [{"@id" "http://example.com/dan",
  "http://example.com/x" 1,
  "http://example.com/y" "y"}]

A compact with a nil @context is effectively an expand. So, I see two approaches here:

1. we can just return what we've got
   or
2. we return properly expanded json-ld

For 2) I think we would need a compact function that works on the node level, as opposed to the iri level which is what we currently have.

[bplatz]

A compact with a nil @context is effectively an expand. So, I see two approaches here:

1. we can just return what we've got
   or
2. we return properly expanded json-ld

For 2) I think we would need a compact function that works on the node level, as opposed to the iri level which is what we currently have.

I mentioned this scenario above and said we should create a ticket that also returns, as an option, all datatypes.

Your example contrasting the two return options isn't a good one - both are technically identical in JSON-LD. There are examples where it would make sense... this just isn't one of them. You'd only need to include @value if you also needed to include @type. Strings and integers are auto-inferred, so it is only needed for data types other than those two, and technically IRIs assuming you used @id (or per spec they are always IRS, like @id and @type always are).

Often those data types can be summarized in an @context also returned, eliminating the need to constantly repeat @type when they are all the same and needing to not include @value at all -- which would eliminate much of this need altogether. Anyhow, a topic for another ticket.

[dpetran]

Going to wait until the fix for #414 lands to complete this.

[dpetran]

I've got a mostly-complete fix in #422 , but that PR doesn't add proper tests for this issue and just introduces the functionality from fluree/json-ld#14