From Filtered Push Wiki
Jump to: navigation, search

Next meeting 2011Oct11

Etherpad for meeting notes: http://firuta.huh.harvard.edu:9000/FP-2011Oct04

No Webex setup. Failover to Skype.


  • Semantic Web Technologies
  • AppleCore examples and mapping



  • Semantic Web Technology discussion
    • Bertram wonders if the technical discussions about the limitations of particular technologies is a sign that we should look for an approach that would be a lot simpler. Do we need all this for the mapper?
    • Bob says the big problem is not the mapper, but the annotation subscription mechanism.
    • However, he believes the duplicates problem is the simplest quality problem we face, and suspects that overall, an OWL representation of the Apple Pie domain will not be very deep. He does not expect a large set of rules, and not many open world issues.
    • Bertram asks if we could get away without using any reasoners, and instead have fixed support for particular vocabularies.
    • Paul says that their experience building the prototype revealed the limitations of more straightforward approaches.
    • Bertram asks if we could start simply, and add more general features later? Bob believes this that extending the mapper in this manner could be very challenging.
    • Bob says that even Darwin Core is being used with differing semantics by different people, because there is no formal semantics for Darwin Core. There are multiple, different XML schemas for Darwin Core (possibly conflicting now, definitely conflicting in older versions that are still in use).
    • Paul says that dealing with the ambiguities in Darwin Core probably is not that challenging. They are things that we can deal with by displaying the information to a human.
    • Bertram refers to an email message from Paul, comparing the represntations of a simple annotation and it's transformation into dwc and then into sql.
    • Bob points out that this example illustrates how annotations need not carry complete dwc records.
    • Bertram asks, how fixed is the usage of the terms used in this example?
    • Paul and Bob says that within the network, in particular for Apple Pie, there could be a fixed ontology and fixed representation of dwc. This would push the real flexibility to the boundaries of the network: inserting annotations and subscribing to annotations.
    • Bob says we are a few weeks from knowing where the semantic-web boundary needs to be. He agrees that it might be practical to shield the mapper from the more general semantic-web technologies, and instead have it use a well defined dwc schema. Filtering (subscribing) is not at all the job of the mapper.
    • Paul points out that the evidence for an annotation, which must be presented to the user, might not be representable in dwc.
    • Tim asks, what is the content of the network messages received by the "mapper"?
    • Bob says that the expectation portion of an annotation does not fit into dwc, but there are only 4 different expectations at the moment and the set of expectations will stay small (and will remain analogous to SQL's insert, update, delete).
    • From the mapper's perpective, an incoming message would include dwc term-value pairs used to identify a dwc record in the local database, more dwc term-value pairs representing new information (for inserts and deletes), an expectation, and the provenance of the annotation (who made the annotation, and when).
Even more important, I think that annotation provenance is largely needed by the parts of an FP client that are pretty much isolated from mapper issues. Such provenance is not about the domain data and will usually have little to do with the taxonomic data, if anything. But human and perhaps software agents who have to decide what action to take vis-a-vis the Expectation may need the annotation provenance data to help make that decision. So somewhere there must be something that bridges the boundary between annotations and client, but that is not the same boundary as between annotations and mapper. Temporally, the provenance-based bridge is likely to precede the mapper-centric bridge, because there is not much use of mapping if the client user is declining to meet the expectations. (The last is not strictly true. One can imagine an agent that wants to make a decision based on what the mapper proposes to do. But again, I suspect that ApplePie's mappers will be light enough that it doesn't matter if it's proposal is computed as part of a decision process. In fact that would probably aid in runtime debugging...) --Bob Morris 13:42, 5 October 2011 (EDT)

Next meeting 2011Oct11