Prefix Management about robot HOT 6 CLOSED

Here's a first pass at a JSON-LD file with common prefixes and prefixes for every OBO project:

https://github.com/ontodev/owltools2-experimental/blob/master/owltools2-core/src/main/resources/obo_context.jsonld

So far I've tested it at on the JSON-LD playground and it's seems to work as expected.

I'd like this to be a comprehensive default, so let me know if I've missed anything important.

The rest of the commit parses the JSON-LD into a map of prefixes, then loads those into an OWLAPI PrefixManager.

from robot.

Any prefix that itself includes an underscore is potentially ambiguous
in the reverse translation. I think we're OK just now but something to
be aware of. I think we wouldn't allow new ones now

Hmm, vHOG should really be VHOG (but not a big deal now VHOG was
superseded by UBERON)

On 15 Apr 2015, at 12:33, James A. Overton wrote:

Here's a first pass at a JSON-LD file with common prefixes and
prefixes for every OBO project:

https://github.com/ontodev/owltools2-experimental/blob/master/owltools2-core/src/main/resources/obo_context.jsonld

So far I've tested it at on the JSON-LD
playground and it's seems
to work as expected.

I'd like this to be a comprehensive default, so let me know if I've
missed anything important.

The rest of the commit parses the JSON-LD into a map of prefixes, then
loads those into an OWLAPI PrefixManager.

---

Reply to this email directly or view it on GitHub:
#9 (comment)

from robot.

We're now using the JSON-LD Java library to parse contexts, then build an OWL PrefixManager/ShortFormProvider. These are the command-line options I have in mind for controlling prefixes:

1. no prefix options: use the default prefixes from obo_context.jsonld
2. --no-prefixes do not use the default prefixes
3. --prefixes FILE (-P FILE) use your own JSON-LD file instead of the default prefixes
4. --prefix "foo: http://foo.com#" (-p PREFIX) add one prefix to the current set of prefixes (may be used multiple times); this should be convenient for projects that have not yet requested an OBO namespace

The --prefixes option will override the --no-prefixes option (it doesn't make sense to use them together). The --prefixes option can only be used once (I think that Apache CLI will take the first). There may be multiple --prefix options, and they will be added after the choice is made between the defaults, --no-prefixes, and the user's --prefixes file.

If you use --prefixes, your JSON-LD file should have a @context key. Otherwise you'll get an empty set of prefixes. The JSON-LD library should try to fetch external contexts. I haven't tested that yet, and it opens the doors to network failures and other unexpected behaviour, but it's an advanced option.

The command-line tool allows multiple subcommands. If the prefix options come before all subcommands, then they are global options that apply to all subcommands. If they come after a subcommand then they only apply to that subcommand. This is our general option scoping rule for subcommands.

This is a little more complicated than I would like, but it's fully configurable, and I think it all follows the principle of least surprise.

from robot.

As I was sitting down to implement this, I noticed that a piece is missing. We should be able to write the current prefixes to a file (or print to console). This will also enable integration testing.

So I plan to add a export-prefixes command that will write JSON-LD. (The name is clumsy, but I like to start every command name with a verb. The verb could be "show" or "write" instead of "export".) If needed, we can add Turtle and SPARQL formats.

from robot.

{export,dump}-prefixes OK with me

from robot.

Had to use --noprefixes instead of --no-prefixes because of Apache CLI option parsing rules.

Closed by commit 6153ee7

from robot.