Changes between Version 9 and Version 10 of ApertureRDF
- Timestamp:
- 10/26/05 12:39:14 (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ApertureRDF
v9 v10 28 28 One change is that the model and model.impl packages are removed from Rio. Furthermore, Graph and GraphImpl have been removed from these packages, as well as all methods that change something in the RDF structure (e.g. Resource.addProperty). 29 29 30 Arjohn explained this decision to me as follows. Have a look at the architecture graphic on http://www.openrdf.org/doc/sesame2/system/ch02.html. The RDF Model at the bottom is the foundation for the rest of the system to manipulate RDF information. It is very awkward and may potentially result in problems when you are able to manipulate the RDF at the model level, as it bypasses the Sail stack and any inferencing, security restrictions, etc. that takes place in it. Therefore these interfaces from now on provide read-only information only. This way it is for example not possible to add properties to Resources obtained from a query result, which may result in indefined behaviour.30 Arjohn explained this decision to me as follows. Have a look at the architecture graphic on http://www.openrdf.org/doc/sesame2/system/ch02.html. The RDF Model at the bottom is the foundation for the rest of the system to manipulate RDF information. It is very awkward and may potentially result in problems when you are able to manipulate the RDF at the model level, as it bypasses the Sail stack and any inferencing, security restrictions, etc. that takes place in it. Therefore these interfaces from now on provide read-only information only. This way it is for example not possible to add properties to Resources obtained from a query result, which may result in undefined behaviour. 31 31 32 32 If you want to manipulate statements, the Repository class is the way to go. It contains methods for adding triples as well as functionality for posing queries, extracting RDF, etc. Furthermore, a number of utility classes (URIVertex, LiteralVertex, ...) are provided that take a Repository as argument and that let you treat the RDF statements as a graph datastructure. 33 33 34 The only drawback of the Repository class is that this resulted in quite a large class. Also, just creating a repository is not enough, it always operates on top of a Sail. This architecture provides great flexibility at the cost of more code complexity.34 The only drawback of the Repository class is that it's quite a big class (note that it is a class and not an interface!). Also, just creating a repository is not enough, it always operates on top of a Sail. This architecture provides great flexibility at the cost of more code complexity. 35 35 36 36 Example: you want to create an in-memory RDF "container" that you can pass to an Extractor: … … 38 38 {{{ 39 39 #!java 40 Repository repository = new Repository(new MemoryStore());41 repository.initialize();42 extractor.doYourWork(repository);40 Repository repository = new Repository(new MemoryStore()); 41 repository.initialize(); 42 extractor.doYourWork(docURI, repository); 43 43 }}} 44 45 Since we're now passing the Repository, we should also pass the document URI so that the Extractor knows for which resource it has to create a CBD. 46 47 The Extractor may then do something as follows: 48 49 {{{ 50 #!java 51 repository.add 52 }}} 53 54 Since the Repository is specified as a parameter to the Extractor, starting and committing any transactions is the responsibility of the integrator. In case of the memory store, these can even be omitted.
