| 214 | | @todo distribution detail |
| | 214 | === Submission Archive === |
| | 215 | |
| | 216 | Whatever the source of the original submission, the submitted source is archived on the server machine (backed up offsite nightly) into an individual, sequenced directory. Each variant of the source, including all step points in transformations through to OWL/RDF is archived in the same place. This allows reconstruction of the submission from any step in the chain of transformations. |
| | 217 | |
| | 218 | === Submission Allocation ==== |
| | 219 | |
| | 220 | In preparation for insertion into the nominated endpoint, non-resolvable identifiers (apart from blank nodes) in the OWL/RDF source are replaced with allocations from the ID generator (again, for the nominated endpoint). |
| | 221 | |
| | 222 | The resulting OWL/RDF submission file is stored in the submission archive with the original submission materials. |
| | 223 | |
| | 224 | === Submission Insertion === |
| | 225 | |
| | 226 | The prepared file with the replaced identifiers is inserted into the specified graph that matches the nominated endpoint (termed a model in a Jena triplestore). This step makes the information available to the public. |
| | 227 | |
| | 228 | === Query === |
| | 229 | |
| | 230 | Any names or designations in the source will be transformed to kinds of rdf:label in the specified graph. Due to the additional indexing and the configuration of cursor-based search in the triplestore, this allows searching for any terms by which the information in the submission is known. |
| | 231 | |
| | 232 | === Presentation === |
| | 233 | |
| | 234 | Once a submission item in question is located (a URI with fragment is provided to identify the submission item), it can be displayed in a web browser simply by clicking on the URI (or pasting it into the address bar). |
| | 235 | |
| | 236 | From here, the server will identify that the client is a browser, and redirect the client to request a CGI encoded-query with the fragment id included, rather than the URI itself bare. |
| | 237 | |
| | 238 | This CGI query results in the generation on the server of a page of content that aggregates information about the submission item. |
| | 239 | |
| | 240 | ==== Presentation Detail ==== |
| | 241 | |
| | 242 | The presentation is interpreted via a scheme developed by IDS-ADI named "infofilter" which is a means of mixing XSLT and SPARQL together with a namespace that allows specification of staged filters built on same. |
| | 243 | |
| | 244 | Since this system utilizes open standards and a manifestly simply filter staging system, it can be edited by those with no knowledge of the specific implementation: SPARQL and XSLT are all that is required to generate the most complex parts of the filter, and by convention in the design of the specific filter stages used, only XSLT is needed for the final transformation into XHTML for presentation. |
| | 245 | |
| | 246 | |
| | 247 | |
| | 248 | |
| | 249 | |
| | 250 | |
| | 251 | |
