Skip to content
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

implement strategy for query loader #10

Open
djogopatrao opened this issue Jul 18, 2014 · 2 comments
Open

implement strategy for query loader #10

djogopatrao opened this issue Jul 18, 2014 · 2 comments

Comments

@djogopatrao
Copy link
Owner

nowadays, only a list of classes is allowed as an input query; upon specification of -query_type sparql, it would accept an sparql query instead.

implementing strategy, we would easily expand this for other query formats.

@djogopatrao
Copy link
Owner Author

@djogopatrao
Copy link
Owner Author

in the current commit ( 307f82b ), stuff like (live_example_property)
query: prop some E and A
domain:
B,C subclassof A
F subclassof E
D subclassof (prop some G)

renders a query specifiying service endpoint1 { prop some E union prop some F }, which may be correct. however, this expansion is being done at QueryExpander.createPatternFromRestriction, failing to check existence of subclasses of E in this endpoint (or others endpoints!).

this inference should be integrated at createPatternFromClasses. there is an underlying pattern between somevaluesfrom and rdf:type that can be used to simplify and generalize the whole algorithm.

I'm commiting as is, so the idea is not lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant