Changes between Version 31 and Version 32 of BluePrint/Importer

Timestamp:

01/22/11 12:31:27 (13 years ago)

Author:

Pat Tressel

Comment:

--

BluePrint/Importer

@@ -180 +180 @@
 === Specifying the schema mapping ===
 
+==== Assumptions and notes: ====
+
 - If the data uses our formatting, we don't need a schema mapping -- we just need
   to be told it's our formatting.
 
 - If the source has a schema that does not match ours, a means of mapping from the
-  source's schema to ours will be needed (or will have to be inferred).
-  (It is likely, for an existing major source, that we would write the schema mapping.
-  For such a source, if we were receiving updates from them regularly, we would want
-  to detect schema changes, or get notification of them.  But for a source we draw
-  on regularly, there may be better means of pulling data than CSV files...)
+  source's schema to ours will be needed.
+  For an existing major source, it is likely that we would write the schema mapping.
+  (But for a source we draw on regularly, there may be better means of pulling data
+  than CSV files...)
+
+- If the spreadsheet importer developed for GSoC has a schema mapping representation
+  that it either receives from the user or generates from having the user match up
+  fields, we should be use the same one. Once past reading in the files and working
+  with the user, the CSV and spreadsheet back-end processes should be equivalent.
+  
+- Inferring the schema mapping, or trying to, might be part of working with the user
+  to establish the mapping. However, people have been working on this since forever
+  (or at least a couple of decades), and automation isn't reliable. If attempted, it
+  should be done with the user at hand to verify it, so it would be done as part of
+  the UI. By the time the back end is called, we should have a schema mapping.