Changes between Version 15 and Version 16 of ApertureSimpleDataCrawler

Timestamp:

10/20/05 11:45:19 (19 years ago)

Author:

sauermann

Comment:

--

ApertureSimpleDataCrawler

@@ -75 +75 @@
 '''Leo> I like this very much, the superclass and sibling idea. I will create objects accordingly'''. We had exactly the same problem of the "graph" structure that was hidden somewhere inside files or folder objects. If we use something like ApertureDataObjectFile and ApertureDataObjectFolder objects to capture and divide this semantic information, perfect. I would argue for ApertureDataObjectFile for things that are 'like a file', so attachments,web pages, web files and local files would all fall into this category. For the ApertureDataObjectFolder I would suggest they are restricted to something like real folders, like file folders, outlook folders or IMAP folders. For things like "attachments inside an email" I would still use the getChildren() idea, and not the Folder thing. Although it may be nice if an email with attachments is both a Folder and a File.
 
+Leo> Another thing that is solved by this solution: Purely Metadata Objects. In ms-outlook, or any address book or calendaring application, you normally don't have files but have many metadata objects like appointments and persons. These would then be only ApertureDataObject instances and return their data on getMetadata() but would not have a content. 
+
 In our use case this also facilitates metadata indexing in because currently our !MetadataFetcher (the class transforming the information inside a !DataObject to RDF statements) interprets the document URIs and "reinvents" the folder hierarchy, modeling it as Resources with a partOf relation. This would then no longer be necessary, the Folder instance would already contain all necessary information.