Changes between Version 69 and Version 70 of rdfstore

Timestamp:

10/30/12 22:07:41 (12 years ago)

Author:

simonp

Comment:

--

rdfstore

@@ -126 +126 @@
  * More...
 
-=== Issues with current patch ===
+=== Review of UWA Developer patch ===
 
 ==== XML2RDF ====
 
-Object Identifiers: One of the stated key advantages of RDF is that objects are identified once and then reused. In the work done to date, I can see that Responsible Parties are assigned identifiers based on the name of the responsible person . Presumably the RDF store would refuse to ingest the same responsible party if it was repeated in another record. But there are a few problems with this approach:
+Object Identifiers: One of the stated key advantages of RDF is that objects are identified once and then reused. In the work done to date, I can see that Responsible Parties are assigned identifiers based on the name of the responsible person. Presumably the RDF store would refuse to ingest the same responsible party if it was repeated in another record? But there are a few problems with this approach:
  - Name of responsible party may not be present (it's optional) or may be hidden
- - The RDF URI is hardcoded to use a CSIRO URL - probably should be GeoNetwork or some other URL
- - Not sure that the SKOS elements are encoded correctly? 
-Perhaps the object identifier could be derived from an md5sum on the content of the object or it may use the XLink URL if the fragment being processed is XLinked.
+ - The RDF URI is hardcoded to use a CSIRO URL - probably should be GeoNetwork or some other URL 
+Perhaps a safer method would be to generate an object from (say) an md5sum on the content of the object? Or if an XLink exists (ie. the content is already shared) then it could use the XLink URL.
 
-Doesn't support XLinked records?
+Doesn't support XLinks records?
 
-Doesn't support parentIdentifer/aggregationInfo methods of creating links to other metadata records?
+Doesn't support parentIdentifer/aggregationInfo methods of creating links to other metadata records? How complete is the mapping from ISO19115/19139 to RDF on http://def.seegrid.csiro.au/isotc211/iso19115/2003/? (a question for Simon Cox).
 
 ==== DataManagerRDF.java ====
 
-Patch uses Apache JENA RDF store but GeoNetwork already uses the OpenRDF-Sesame RDF store for its SKOS vocabularies - would be better to use one of these RDF stores, not both?  
+Patch uses Apache JENA RDF store but GeoNetwork already uses the OpenRDF-Sesame RDF store for its SKOS vocabularies - would be better to use one of these RDF stores, not both?  (Perhaps OpenRDF-Sesame doesn't support something needed here?)
 
-When storing metadata records in the database table, they are allocated an integer ID in DataManager. I need to check that the DataManagerRDF code continues this practice otherwise the permissions system and other parts of GeoNetwork will not be able to manage the record properly.
+DataManagerRDF adds extra methods to DataManager that (at the moment) simply store the metadata record (in RDF) in the RDF Store - this is a duplicate of the metadata stored in the database (which is fine for test purposes). These methods seem to be coded efficiently. Unfortunately the only mapping to RDF currently supported is the ISO19115/19139 mapping on http://def.seegrid.csiro.au/isotc211/iso19115/2003/. GeoNetwork also supports other metadata schemas (eg. Dublin Core, ISO profiles etc). Simple checks need to be added to DataManager to avoid calling DataManagerRDF if the schema of the metadata record does not have a mapping to RDF. This could be achieved by moving the xml2rdf.xsl and rdf2xml.xsl XSLTs from web/geonetwork/xsl to the convert dir of the iso19139 plugin schema and then implementing a check to see whether these XSLTs exist in a particular plugin schema in DataManagerRDF (this is a small change that would make the current patch work better with GeoNetwork).
+
+==== Other Java Changes ====
+
+I 
 
 ==== Implications for wider adoption of RDF Store and Encoding in GeoNetwork ====