1. Doug Burke
  2. swish


swish / TODO

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

- Move ListHelpers into an Internal module (do we export flist?)

- Support IRI rather than URI. See issue #13

- Look at using an interned URI in Namespace.

- Rename modules. Version 0.7 provided a hopefully more-structured
  form but they are still in the Swish namespace rather than
  Data (or some other sanctioned top-level name).

- Check test coverage since the removal of some of the routines
  (e.g. those in ListHelpers) has lead to the removal of some tests:
  GraphTest select/pairSort

- Should the Lit/LangLit/TypedLit constructors of RDFLabel be moved
  into a separate constructor - e.g. 

    data Literal = PlainLit T.Text (Maybe LanguageTag) | 
                   TypedLit T.Text ScopedName

  since this is closer to the RDF semantics, and may make some operations
  a bit easier?

  Note that there is a possibility that Lit x is going to be
  considered to be TypedLit x xsd:string - see issue #14

- add RDF/XML parser and formatter. See issue #7

  Ditto for JSON-LD/the various named-graph forms/...

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

- can items be moved out of Swish.RDF.RDFGraph (e.g. the RDFlabel

- do we need to export rdfQuerySubs2 from Swish.RDF.RDFQuery (since this
  is used by rdfQuerySubsAll/rdfQuerySubsBlank do we need to explicitly
  test it)?

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

- 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 as fgl
  expects it.

- 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)

- 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?

- 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)

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 unchanged (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