Combination of DESCRIBE and CONSTRUCT

[namedgraph]

Why?

DESCRIBE is useful for getting resource descriptions, without having to provide a template as in CONSTRUCT.
However sometimes the use case requires adding just a few computed values to the description.

Previous work

None that I know of.

Proposed solution

DESCRIBE ?s
CONSTRUCT
{
    ?s some:property "value .
}
WHERE
{
    ?s ?p ?o .
}

Considerations for backward compatibility

Won't work out-of-the box on SPARQL 1.1 processors, but could be combined from

DESCRIBE ?s
WHERE
{
    ?s ?p ?o .
}

and

CONSTRUCT
{
    ?s some:property "value .
}
WHERE
{
    ?s ?p ?o .
}

[cygri]

Would the use case be adequately addressed by allowing a query to consist of multiple graph-producing queries?

PREFIX ...
DESCRIBE ...
WHERE {...};
CONSTRUCT {...}
WHERE {...}

If that is not sufficient, and a combination of CONSTRUCT and DESCRIBE with a single shared WHERE clause is needed, then perhaps this would be better:

CONSTRUCT {
    DESCRIBE ?s
    ?s :prop "value"
}
WHERE {
    ?s ...
}

That would play well with #31 because one could choose the named graph that the DESCRIBE result goes into. Edit: Doesn't really work, because one needs to say what named graph the data comes from and which one it goes into.

[kasei]

@cygri This might also have some overlap with #6 if we were to have a function version of DESCRIBE which was table-producing...

[cygri]

@kasei Do you mean as an s/p/o table? Why would we want that?

[kasei]

@cygri because it would give you access to the data being produced by the DESCRIBE that could then be augmented before being used in a CONSTRUCT? I don't personally have any use cases for this (or for the combination of DESCRIBE and CONSTRUCT being described here), but thought there might be some overlap with other proposed features...