| 83 | | * we could say that datasource config is done using servlets - then it is easier to reuse |
| 84 | | * we could use the same crawler / registration classes in Nepomuk, Autofocus, and AMS(what is ApertureCrawler and ApertureDataSourceRegistry in gnowsis) |
| 85 | | |
| 86 | | '''Suggested Vocabularies to use for Crawled Data''': |
| 87 | | * [[WikiInclude(ApertureVocabularies)]] |
| 88 | | |
| 89 | | Another thing to work on is an agreement (or consensus that there should be no agreement!) on what values these properties can take. For example, does a given property only allow Literal values or also other Resources, how are data types like dates encoded, what value can a language property take (e.g. only "en" or also "en-us", lowercase vs. uppercase, ...). This goes beyond the choice of a specific XML Schema data type. |
| 90 | | |
| 91 | | About email senders and receivers: they are now modeled as a URI of the form "email:<address>" with a name and address property. Of course people can use different names in combination with the same address. You definitely want to be able to retrieve the specific combination used in a specific mail. In Aperture applications this is now typically solved by using contextualized statements. This already goes wrong when the same address is used multiple times in the same mail. This often happens with mails obtained from a mailing list: the From and To use the same address but a different name. Also this gets problematic for RDF applications that cannot use context (e.g. because their RDF store does not support it) or they cannot use it in a DataObject-centric way. |
