Right now, env.lookup() will return either the RDF term bound to the identifier, or the Template object bound to the identifier.

Suggest env.lookup() should only ever return RDF terms, and a new get_template() or similar be written for templates, so that identifiers which happen to be templates can be used for property names, variables etc.

The syntax for QNames in 1.0 is <prefix>:<localname>, not <prefix>.<localname>.

This is because <expr> is a first-class, <toplevel> construct in 2.0, but not 1.0, and QName's can be expressions.

This problem could be resolved (although it is perhaps not even a problem), by including some precedence rules in the parser.py grammar for <expr>s and <instanceexp>.

Positional information needs to be kept in Parameter objects, so that arguments can be correctly assigned to parameters.

Parameter constructor takes a position argument, but the list is built backwards, which means the easy solutions are all hacky.

It is not currently possible to parse multi-line strings using parser.py.

In 1.0, multi-line strings are delimited with '{' and '}'. Although multi-line strings should be supported in future versions, I prefer the pythonic syntax, using either \ string continuation or the triple quotes.

e.g.

string = "This is a "\ 
"multi-line string"

or ...

string = """This is a 
multi-line string"""

Probably better to have an ExtensionError that extensions can raise and authors can subclass.

The method should check if the prefix is already bound in the rdflib.Graph, then handle this case appropriately, either overwriting the previous binding or signalling an error.

The current grammar allows for QNames or URIs to be given as parameters for a constructordef, this does not make much sense semantically.

The syntax should be changed to only allow SYMBOLs to be named as parameters.

The RDFScriptError messages report position as number of characters from start of the file, not the start of the line.

There is a lot of places in the codebase where it is necessary to check what type of syntactic construct something is.

This happens enough to justify a TypeCheck module that will offer functions like isX(thing) that will return True iff. thing is a valid X construct.

A graceful error handling system need to be written and linked to Env, so that Env can signal error conditions such as wrong type, no such prefix etc.

Env.assign() should check that:

• identifier is a URIRef, and does not already have an assignment, or handle this case in some defined way
• value is really a rdflib.term

QNames, as far as I know, are an XML thing.

Should these then really be appearing in the rdfscript syntax, since it works with rdf graphs?

Perhaps renaming QName to Identifier would be clearer?

Test coverage is poor.

The only tests that exist are for the reader and the parser, there are no tests addressing how the rdf graph is constructed for example.

If given a wrong number of arguments, an expansion raises an InternalError at the point a Parameter is passed to the RDF graph.

A more appropriate behaviour is needed, that highlights that the wrong number of arguments were given.

The import statement should search the path for the given import. At the moment only the directory containing the file being parsed is searched, and the code that does this is clunky.

The syntax for ShortBOL2.0 will necessarily be different to that of ShortBOL1.0 if 2.0 does not keep track of indentation levels and certain whitespace.

An example of this is instance expressions in 1.0, where the indentation defines a block statement filled with property expressions.

A choice needs to be made whether the 2.0 syntax should mirror exactly that of 1.0, and if so, 2.0 must keep track of indents at a minimum.

The case in which a chained prefix evaluates to a value is not handled, for example:

@prefix p = <uri>
p.x = "value not  a uri"
p.x.y

Will cause an error because p.x is not a Uri.

The expected behaviour would be for p.x.y to evaluate to <urixy>

It would be useful to have a EBNF grammar that could be processed by PLY.yacc, even if just as an exercise to nail down the syntax of 1.0

Absolute imports don't work. The Importer import_file method should make a last attempt at absolute import if all else fails.

The Importer module relies on pathlib, which is only available from Python 3.4.

Python2 compatibility depends on a os.path based implementation. Then the project should support Python2.7 at least.

It would be useful to be able to refer to the name of the expansion within templates and expansions, particularly if this could be passed over to extensions.

As the title says, similar to the this keyword in Java, self in Python etc.

If there are no matching namespaces in the rdflib.Graph, this should be handled in a well-defined way.

Should the language include operators on its data types?

For example:

• compose(concatenate) two URIs? Split URIs?
• arithmetic?
• test for equality?

Giving extension authors access to the Env object of the interpreter is probably fine while no-one is writing their own extensions and the number of built-ins is small. However, before a first release, the Env should be covered up and extensions given access to some abstracted version, otherwise Env would have to be extremely stable.

So, a new abstraction on Env is needed that can remain stable for extensions, but allows Env itself to change.

The prefix argument to resolve_name, if given (not None) should be an existing prefix bound in the rdflib.Graph.

If it is not, there are two possibilities, create the binding, or signal an error condition.

Suggest changing @defaultPrefix x to just @prefix x.

Also @prefix on its own could evaluate to the current default prefix.

At the moment, test_parse_shortbol1_examples.py tests whether parsing the stdlib produces the correct toplevel AST objects. However, it would be good to test whether the child AST objects are parsed correctly too.

Tests should be written that check whether stdlib is parsed correctly at all levels, not just toplevel.

Suggestion to add a `@extension' pragma or similar, that will hook into a custom written extension to do some processing of RDF triples.

Eg:

Identified(name, type) =>
  sbol.displayId = name
  @extension sbol.Identity

sbol.Identity might do something like set persistentIdentity Identity, version with compliant URIs based on sbol.displayId

ShortBOL2 needs a list expression type so that multiple value property expressions can be implemented.

This is so that templates for things like SBOL2 ComponentDefinitions can have many sequence properties.

Since indentation can't be used in the REPL, and would be clunky anyway, users can't define templates or add properties to expansions at the command line.

Either:

• Change the grammar in the REPL to allow for properties to be added.
• Change the grammar so no longer relies on indentation levels.
• Change the REPL so it knows when to about line continuation and indentation.