almibe / ligature-specification Goto Github PK

Right now I use name for Dataset and Attribute, and I use id for Entity.
I should probably just pick one to be consistent.

Instead maybe just have a function that constructs statements or support tuples?

Instead of requiring that an identifier starts with a-z, A-Z, or _, maybe I could make them just strings of valid url characters???

• Standalone
• Instance
• Dataset
• QueryTx
• WriteTx

remove attribute

remove floating point numbers

add identifier type

update identifier definition

• Get rid of dot calls as they exist
• Only use dots for calling code in Modules
• Add pipe forward operator |>

Small Steps to Work on Stroll

• am I sure I want to make it required to put #read or #write at top of script?
• I think there are only two ways to modify the datastore in a script ($.add & $.remove) so it could be detected
• I should probably leave that out since it's kind of weird/will lead to annoying problems when developing scripts
• first support comments and empty scripts
• update grammar in stroll-grammar
• update parser/ast in stroll & test
• add example scripts & tests (an empty script or script with just comments should return a JsonNull JsonElement)
• then start supporting @Prefix and @base statements
• test error conditions like declaring more than one base or overriding a prefix name
• then start supporting basic let statements
• literal types to support
  • string
  • numbers (figure out how I want to handle numbers ie what/how many types there are)
  • iri (a regular one and ones that test prefix and base as well)
  • statements (with default graph and named graph -- also test supporting the a keyword within a statement)
  • pairs (via the 'to' keyword)
  • ranges (via the '..' operator)
  • anything else?
• update grammar/parser/ast/tests along the way
• test error conditions/corner cases
  • let = #no assigment
  • multi-line let
  • assigning a let twice
  • assigning without let
  • invalid iris and statements
  • invalid strings
  • invalid ranges
  • invalid pairs
  • use a variable to create another variable
• add support for return statements
  • return all literal types
  • return variables
• test corner cases
  • return return #should be an error
  • multiple return statements in a row (I think this should be fine since a script just exits when it reaches the first return statement)
  • return by itself should return JsonNull
• add support for function calls
  • initial support should parse and build ast but running scripts should always result in errors
• add support for method calls
  • initial support should parse and build ast but running scripts should always result in errors
• start to add support for collection types
  • test initialization (via function calls) and returning them (should return correct JsonElement with values)
  • test method calls (figure out apis & document & test)
• add support for graph data type
  • test initialization and return them (should return a set of statements)
• add support for $ variable
  • test supported methods & non-existing ones
  • returning the $ should return a set of statements
  • assigning $ should be an error
  • changes to $ should persist across script calls
• add support for lambdas
  • test defining
  • test calling
  • return a lambda should be an error
  • returning a call to a lambda should return the result of the lambda
  • test cardinality
• add support for when expressions
  • ...
• add support for functions supported by SPARQL
  • ...
• add support for calling external services (web services + SPARQL endpoints)
• add support for math and string manipulation (first figure out how to do this)
• what else???

Instead of null use nothing or none keyword

NOTE: double check what's in almibe/slonky and document that

I don't think it makes sense to include this as part of the spec and instead for now http api access should be designed per specific application.