1.  Status definitions
2.  Issues

1. Status definitions

2. Issues

ID Title Status
1001 The ability to retrieve entire statements from a versa query. http://versa-rdf.org/issue-status#RECOMMENDED
1002 "class" core function. http://versa-rdf.org/issue-status#RAISED
1003 "value" core function. http://versa-rdf.org/issue-status#RAISED
1004 "rdfList" core function. http://versa-rdf.org/issue-status#RAISED
1005 "rdfCollection" core function. http://versa-rdf.org/issue-status#RAISED
1009 Extension function mechanism http://versa-rdf.org/issue-status#PROPOSED
100B Better definition of entialment in Versa. http://versa-rdf.org/issue-status#RECOMMENDED
100C QName helper functions. http://versa-rdf.org/issue-status#RECOMMENDED
100D First class sub graphs. http://versa-rdf.org/issue-status#RECOMMENDED
100E transitive closure function. http://versa-rdf.org/issue-status#RECOMMENDED
1000 Support for Literals and Datatypes. http://versa-rdf.org/issue-status#ACCEPTED
1006 [] as existenstial placeholders in filter and traverse functions. http://versa-rdf.org/issue-status#ACCEPTED
1007 list slicing and indexing. http://versa-rdf.org/issue-status#ACCEPTED
1008 Boolean operators < <= > >= <> and !=. http://versa-rdf.org/issue-status#ACCEPTED
100A Support for backwards filter. http://versa-rdf.org/issue-status#ACCEPTED
100F Quote Madness http://versa-rdf.org/issue-status#ACCEPTED
1010 Move towards N3 URI references http://versa-rdf.org/issue-status#ACCEPTED
1011 semi colon after expression for a query http://versa-rdf.org/issue-status#ACCEPTED
1001: The ability to retrieve entire statements from a versa query.

It is desired to retrieve entire statements from the RDF model.

Discussion Proposal: The current proposal is to modify the traverse and filter function calls to take an optional "result type" parameters. One option for the results type would be statement. Additional, a set of functions will be added to tranlsate a statement (or list of statements) into the individual components of the statement. These function would include "subject()", "predicate()", and "object()".
1002: "class" core function.

The addition of a core function the returns the rdf:type(s) of a resource.

Discussion
1003: "value" core function.

The addition of a core function the returns the rdf:value(s) of a resource.

Discussion
1004: "rdfList" core function.

The addition of a core function the returns a Versa List from a rdf:List data structure.

Discussion
1005: "rdfCollection" core function.

The addition of a core function the returns a Versa List from a collection data structure.

Discussion
1009: Extension function mechanism

Update the specification to talk about how extension functions should be supported by implementations.

Discussion Proposal: Add a section 7.7 to the specification that discusses function namespaces and extension functions. A function w/o namespace is assumed to be in the versa core functions namespace. Any other namespace, must be registered with the implementation and resolved accordingly. Additional, the ebnf should be change so that the "identifier" for a function follows the xml qname production.
100B: Better definition of entialment in Versa.

Update the specification to be more clear on what entailment Versa implementations are required to support.

Discussion
100C: QName helper functions.

Update the specification to be more clear on what entailment Versa implementations are required to support.

Discussion
100D: First class sub graphs.

Instead of adding statements as first class data types, add sub graphs as first class data types.

Discussion
100E: transitive closure function.

Apply an expression transitively, starting with the given set of values (resources), making sure to avoid circularity. The expression could return nested lists/sets, in which case, every object in the topmost list is searched for a resource terminating the leftmost path in the tree and the found objects are used for the next transitive lookup.

Discussion
1000: Support for Literals and Datatypes.

It is desired to add support for literals and datatypes to the query language.

Discussion Proposal: The current proposal is to add a literal datatype to the specification. This includes updating the specification for conversions between the new data type and the existing datatype. It also requires adding functions to support the access of the literal datatype.
1006: [] as existenstial placeholders in filter and traverse functions.

To simplify queries that use blank nodes, the following "(all() |- ns:price -> lt("30")) - list(dc:title,ns:price) -> *" could be represented as "[ - ns:price -> lt("30")] - list(dc:title,ns:price) -> * "

Discussion Proposal: This is accepted and the grammer will differentiate between the uses of '[]'
1007: list slicing and indexing.

Update to the syntax to allow slicing and indexing of a list. the [] operator is common for this, however it may clash syntactically with Issue 1006. Also support for the "in" operator.

Discussion Proposal: This is accepted as specified. The grammar handles the issues between this asn issue 1007
1008: Boolean operators < <= > >= <> and !=.

Update the syntax to allof these as operators.

Discussion Proposal: This grammar has been updated to accept this.
100A: Support for backwards filter.

Update the syntax to allow for a backwards filter. It would be conceptually similar to the forwards filter, but backwards.

Discussion Proposal: The current proposal is to update the specification to support "expression "-|" expression "-" expression". This would start at an object set , filter based on the predicate and subject expression and results in the objects for all statements that match.
100F: Quote Madness

Determine a better way to nest expressions so that quotes do not get out of hand.

Discussion Proposal: Allow sub expression of '{ expression }' for arguments to functions
1010: Move towards N3 URI references

Replace @URI with <URI>

Discussion Proposal: Modified the resource-literal production to look like "resource-literal ::= ('@' string-literal) | uriref". Also added a uriref production of "uriref ::= '<'[\>]* '>'"
1011: semi colon after expression for a query

The current EBNF defines a query as "expression". The current bgen defines a query as "expression ';'?". Which way is correct?

Discussion Proposal: semicoln is used to seperate the declarations and the query.