1. Doug Burke
  2. swish


swish / TODO

Some things I want to/should do (not in order)

- Should there be a type-level constaint that an RDF Arc can only have
  a literal in the object position?

- the RDFLabel data type could be split up to add additional type
  constraints, namely Lit could be split up into something like ULit
  for an untyped literal, LLit for a language lit coupled with a
  LString type that combines text and language tag), and DLit for a
  literal with a datatype. This would require a minor version update

  An alternative change would be to make it 'Lit RDFLiteral' with
  RDFLiteral having the Untyped/Typed/Language options.

- move a lot of parser/formatter tests out to ntriples files (ie the
  test data in external files).

- turtle parser, then RDF/XML.

- look at using fgl rather than existing graph code (may or may not be
  worth it), especially given that it's not really a graph

- look at using something like a TextBuilder for processing output

- profile (have added the -fdeveloper cabal flag which can be combined
  with the --enable-library-profiling and --enable-executable-profiling

- improve test coverage (-fhpc cabal flag)

- how much of the support code - e.g. Swish.Utils.LookupMap - can now
  be replaced with packages from hackage?

- can we improve the processing of the commands, so that they
  exit on error immediately, with a single error message.

  An EDSL for the command language or for the base components
  such as RDFTriple/Graph?

- remove the containedIn function of the LDGraph type class,
  or implement it. It is currently unused in the code base.

- would it make sense to add some form of XSDType type class which
  would contain to/from and show canonical String methods and some
  form of equality test; these could then be used to create the
  RDFLabel instances and the showCanon RDFLabel routine? Need to think
  about this as technically it need not be restricted to XSD types.

  Errr, there is Swish.RDF.Datatype which looks to have the
  semantics we need (ie remove the To/FromRDFLabel typeclasses); 
  it may still be useful to have a typeclass for conversion between
  strings and values for the formatter/parser code (such as,
  perhaps, Swish.RDF.Datatype.DatatypeMap)

Text conversion:

  - converting to Text in pieces, so lots of conversion via String
    is apparent. This needs fixing, including
    to convert to/from Text rather than String

Issues in the conversion to URI for Namespace/QName/...

* parse issues

  @prefix : <file:///home/swish/photos/>.
  @prefix me: <http://example.com/ns#>.
  :me.jpg me:photoOf me:me .

Is foo:me.jpg or :me.jpg valid? From my reading it is, but the '.' is
potentially confusing.

* base URI

cwm rejects base URIs ending in # (need to try with a fragment as this 
observation may be incorrect or fixed now).

* Issues with the default prefix

With the input file

  @prefix : <file:///home/swish/photos/>.
  @prefix my: <http://example.com/ns#>.
  :mejpg my:photoOf my:me .

old Swish will round-trip this to

  @prefix : <file:///home/swish/photos/> .
  @prefix my: <http://example.com/ns#> .
  :mejpg my:photoOf my:me .

but the current code creates

  @prefix : <file:///home/swish/photos/> .
  @prefix my: <http://example.com/ns#> .
  <file:///home/swish/photos/mejpg> my:photoOf my:me .

This happens when the default prefix is <http://foo.bar/baz/>, so
it is unrelated to file.

If we use a named prefix then things behave as expected: ie

  @prefix p: <file:///home/swish/photos/>.
  @prefix my: <http://example.com/ns#>.
  p:mejpg my:photoOf my:me .

is passed through unchnaged (except for an additional @prefix statement
getting added).

Need to add a test of this. Of course, the issue is what should the default
namespace be on output; the one chosen from the input graph but then what
if the input is from ntriples or there is another namespace with many more