-
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
Use of config file for semantic predicates #1
Comments
Indeed, the current approach is a bit brute, with a hard-coded collection of common predicates; this is not great. Lines 12 to 24 in 7b3e1c4
I guess we could have this as default, with the option to override it |
I see, perhaps an option is to store that list of predicates in a separate file and point the user towards it if they want to customize predicates - though that does reduce it's "easy to re-use" factor significantly. However, forcing a user to input specific iri's as arguments in a command line tool is also not optimal. It does not have to be as complicated as we did it in respecter though, that's for sure. What do you think is less user-unfriendly? I definitely foresee use-cases where the current list of predicates will not suffice for indexing. |
How about adding a CLI option like:
This would require minor API changes, likely making this list an attribute of TermMatcher instead of a constant (better practice anyways). We could provide an
|
Yes, I like it! |
Given that we want to be able to use multiple kinds of ontologies, we should allow the user to somehow specify which predicates to use, as not all ontologies will use rdfs:label.
One possible solution is to configify this similarly to how respecter does it.
Alternatively, we could support some basic ones and handle this in the CLI (pre-filled options for skos, rdfs, dcat, schema etc. which a user can choose with a flag like -pred)
fuzon -predscheme skos - input ont1.ttl ont2.ttl
This would mean skos:prefLabel, skos:altLabel and maybe even skos:definition or skos:example get used as the prefixes on which to SPARQL.
The text was updated successfully, but these errors were encountered: