Difference between
version 5
and
version 4:
Line 19 was replaced by line 19 |
- However, if we were to require data providers to write 'AIS files' with EML that was then to be merged with the data set's information to build the DDX, we really would not have solved much, if anything. The same basic problem(s) would remain - the collection of information would grow stale. |
+ However, if we were to require data providers to write 'AIS files' with EML that was then to be merged with the data set's information to build the DDX, we really would not have solved much, if anything. The same basic problem would remain - the collection of information would quickly grow stale. Instead we will isolate specific parts of the EML document that are needed for the metacat/kepler combination and generalize those. The generalized 'micro-documents' will be based on ISO19115 to the extent possible and the result merged into the DDX. A DDX-->EML transform (implemented in XSLT which is supported by metacat) will actually generate the EML documents. This provides two important sources of leverage in this design. First, since the source information is more general than EML itself, it should be easier to motivate data providers to write it. Second, the same source information can be used to build other kinds of records used by other search systems. |
Line 21 was replaced by line 21 |
- Why will storing information in the 'AIS files' work when writing full EML records doesn't? First, the AIS files will be closely bound to the data sets they describe, so they providers will likely move those AIS files when they move the data files, either when the data move within a host or between hosts. Second, the AIS files will use |
+ While not in the scope of this design, this AIS --> DDX --> EML data flow provides the basis for more sophisticated processing than XSLT can provide. |
Removed lines 23-24 |
- We have experimented with searching solutions that depend on server's |
- |
Back to Ocean_use_case_searching,
or to the Page History.
|