edgardmarx
commented
3 years ago I will go a bit further and simplify a bit by removing the partititions and Entity and leaving a "graph" keyword after construct. E.g.
CONSTRUCT GRAPH {
?pub
rdfs:label ?label ;
dct:creator ?content ;
eg:sortKey ?firstAuthorName .
?content foaf:name ?name .
}
WHERE {
?pub
a conf:InProceedings ;
rdfs:label ?label ;
bibo:authorList ?list .
?list
conf:hasFirstItem/conf:hasContent/foaf:name ?firstAuthorName ;
conf:hasItem/conf:hasContent ?content .
?content foaf:name ?name .
}
ORDER BY ASC(MIN(?firstAuthorName))
LIMIT 100
OFFSET 50Notice that this allows you to build any graph in the construct, not just entities. Further, you are specifying that the construct is a graph instead of triple centric. Finally, you do not need to specify the "start" of the graph (partition) as you can extract the same subgraphs starting by any of the variables in the construct.
Aklakan
namedgraph
VladimirAlexiev
afs
TallTed
justin2004
(Apologies for re-opening #127 as a fresh issue, but in my attempts to clarify the initial proposal I got lost in considerations of technical details and corner cases so that by now my feeling is that I turned it into an incomprehensible mess from which it is no longer possible to judge whether the core idea is of interest or not to the community)
Why?
Consider this analogy: OWL as a description logic language is entity centric: A class expression intensionally describes a set of entities satisfying a given set of constraints. This is akin to a SPARQL SELECT query with a single variable. However, in both cases it is not possible to specify in the same query a corresponding RDF graph fragment for these entities.
In contrast, SPARQL construct queries are triple-centric. Yet, while it is possible to specify the RDF graphs to create from retrieval, it is not possible to specify in a standard way to which entities the triples belong.
As a consequence, so far it is not possible to have a SPARQL query that semantically describes a set of 'objects' - i.e. a 'thing with an id' together with an RDF graph fragment that describes it.
SPARQL is not a graph traversal language and this proposal is not about making it one, but having a standard way to designate entities together with their graph fragment would foremost provide a direct connection point for other path-based languages / approaches such as LDPath or LDFlex.
An example, consider this use case: "From the SPARQL endpoint of scholarlydata retrieve the first 100 publications together with all authors ordered by the name of the first author".
At present, to the best of my knowledge, the query would have to look like this:
with the response
The response now is just a bunch of triples. Let's assume an application should display an html template
<span>{{resource.label}}</span>- which resource should it match? The query response does not tell it where to start. Of course the application could just pick any resource with a label - but what if authors and publications both have them? So we would add a special type to CONSTRUCT query so that the application can pick it up. Now the application that should just display a title of something passed to it needs to be aware of ontology metadata. (And of course, the application by the consortium member uses the same approach using a different class)Previous work
Custom solutions involving query transformations, use of vocabularies to annotate resources in the construct template, and post processing of SPARQL query responses.
Proposed solution
The proposal comprises three things:
The response for this query is a sequence of partitions in the order as specified in the query. The partitions could be represented as named graphs with random-generated IRIs on query execution and thus most unlikely to clash with any data in the payload. A to-be-standardized property attached to this named graph IRI could be used to state which entities within that graph were declared to act as starting points. The specification could guarantee that partitions are always exposed as consecutive quads. A change in the named graph IRI thus marks the end of a partition. As a result, path based approaches could directly 'connect' to the designated entities and traverse the data in of the partition's graph fragments.
Considerations for backward compatibility
None