Create an archive/container format for publishing Playtools data (specification)
N3, while very easy to type and read, does poorly at structured hierarchical documents. XHTML does fine with these. Allow a subset of XHTML to be stored right alongside the N3 data so that things can have human-readable descriptions, organized in paragraphs with headings and emphasis and bulleted lists and links.
Use Cases
Author wants to publish his new creature, the chthonian. He defines the monster in N3, but then he wants a description. [extra non-N3 syntax files--] For this, he creates an RDF-XML document which contains parts in the XHTML namespace, allowing him to rich-text format his description. Because N3 is not XML syntax, he must put the description into a second file.
[embedded resources--] Then he draws a picture of the chthonian, and wants to include it. His application (an initiative roller) is not able to use HTTP and expects custom creatures to be in a single Playtools-format file per monster. He drops his image into the container, adds a reference to it and is done.
[distribution format for related documents--] A friend of his begins to design a chthonian monster template, so you can have e.g. a chthonian zombie by applying the template. This project is taken to completion and then abandoned; original author takes the resulting N3 document and wants to include it in his all-things-chthonian distribution, but keep it separate because it has a different author. He adds it to his container.
Outcomes
When this blueprint is implemented, we will be able to:
- Run a command on several files (or: one manifest file) that creates a single-file distribution of related Playtools files.
- Provide an API to apps that want to read Playtools containers
Provide an API to apps, such as converters, that want to write Playtools containers
- Have a better name for this thing than "Playtools container"
Implementation
Create a command-line tool that will package an N3 file with associated XHTML resources, in a jar- or egg-like format. Write an API to create the files, open/read them into our RDF API, possibly edit them in place. Probably not in scope: publishing and retrieval of the files over HTTP (should be addressed somewhere else).
Open Questions
- Do we need links?
- Do we need external resources (e.g. image references)?
- Do we need embedded resources?