-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linked Data Fragments Query Result format discussion: #40
Comments
Is there a reason we want to avoid this? Wouldn't that break with the URL/URI/IRI specs?
Requiring The cleanest interface is documented at: http://www.rubydoc.info/github/ruby-rdf/sparql/SPARQL#execute-class_method |
The main reason is just that we haven't been using URL parameters in the application thus far. For example, to resolve a URI, one does: I wanted to keep the query interface consistent with the subject resolving endpoint. Hence the last comment on if we are going to use url parameters for the query, then should the subject resolver now be: Thanks for the clarification on how to do SPARQL queries against a Repository endpoint! |
IMHO Values of query parameters should be URI escaped, for exactly this reason. The server, when extracting the parameters would then URI unescape to get the actual query. |
This is not my understanding of the current implementation. Don't do something more like: If the goal is just to support sparql syntax, I think we could probably mount a SPARQL endpoint at I'm still inclined to support something like a strict lucene subset, but am working on figuring out client side needs for my project now. |
My sample URL there is from the README of this project. You are correct that your example would also function but it wasn't the preferred url format to use at this point. Hence the discussion on changing the documented way to resolve uri's to rely on url parameters to be more consistent if the query interface would require using them.
I believe the goal is to support Linked Data Fragments, not SPARQL. The Linked Data Fragments application needs to translate the fragments to a query the underlying cache layer can understand. Unless there is a Linked Data Fragments compliant endpoint that supports fuzzy string matching for Marmotta and Blazegraph that I am unaware of, that means turning the queries into SPARQL that those caching layers understand. In the future, we can have backends that don't know SPARQL or Linked Data Fragments that might require a different translation. Furthermore, the point of Linked Data Fragments is to reduce complexity and allow for better caching of queries on the server side. But beyond that, I'm not fully opposed to a SPARQL passthrough endpoint beyond supporting the Linked Data Fragment interface though. |
Can you clarify what you mean by this? Is there a Fragment spec you have in mind? I understood that this search discussion was targeted at defining such a spec. If we're translating to SPARQL under the hood, I think we need to be really specific about what complexity is reduced by introducing a new syntax; SPARQL Construct is already defined as a fragment and implemented. Are there use cases here that aren't covered by extending either SPARQL Construct or Triple Pattern Fragments to support lucene style fuzzy searches? |
I believe every example of triple pattern fragment queries I have seen has used the following URI syntax (note the URI escaped parameter values):
However, the TPF spec provides some alternative examples. I believe unspecified values (ie. an "open match" pattern like s?) are simply left empty. As for fuzzy string matching, you may want to look at the interfaces beyond TPF -- in particular, Substring Filtering for Low-Cost Linked Data Interfaces has a discussion of suggested free text search fragment syntax. |
In the current implementation, the base Unfortunately, the Substring Filtering paper's proposed syntax is just I'm looking at this closer, but for now, the syntax I would propose is:
as in:
or:
Where all the variables are support some kind of lucene like phrase; as in:
It's even less clear to me how to express this latter example in the Hydra Core Vocab. |
Note that @no-reply's Feb 10 comment documents the approach we all agreed on. @scande3's pushed his work in progress branch: https://github.com/ActiveTriples/linked-data-fragments/tree/feature/ldf_query_experimental. Anyone interested in continuing this work could start from there. He commented that this branch "has an updated README. I tested it again locally so let me know if there are problems if you try it. Note that it gave me an error in Ruby 2.4 for some reason so I switched back to my older Ruby 2.2.x version" |
http://localhost:3000/?q=?o ?s "^Las*"
http://localhost:3000/?q=?o ?s "(?i)^Las*"
For the Repository in-memory interface, how does one do a SPARQL query against that graph? Is there an example @no-reply can link me to on how to do case insensitive string matching for the Repository interface? I may just be looking in the wrong place for that type of example.
For the current subject resolution, should that remain the same? Or to be more consistent with the new query interface, should that be:
http://localhost:3000/?s=<subject uri>
The text was updated successfully, but these errors were encountered: