IW Meeting 2013-10-10

From Inference Web

Jump to: navigation, search


Meeting Information



PROPOSED: rename fromAnswer to pml:ledToAnswer subproperty of prov:hadDerivation, range is pml:Answer, domain is pml:Information .

OWL publishing pragmatics

TODO: Jim to figure out why PML3 OMN files don't load in recent Protege versions. (precondition for other Jim tasks) Todo: also update a static link to an owl file of the newer version (once previous version is debugged )

(Tim runs a local "pml-3.0.sh" to aggregate all of the module's omn into pml-3.0.owl)

pml:Map vs. prov:Dictionary

We currently have pml:Map, but that needs to be reconciled with prov:Dictionary.

"Conceptually, a dictionary has a logical structure consisting of key-entity pairs. This structure is often referred to as a **map**, and is a generic indexing mechanism that can abstract commonly used data structures, including associative lists, relational tables, ordered lists, and more. " - prov-dict

Example of a prov Dictionary: (http://www.w3.org/TR/2013/NOTE-prov-dictionary-20130430/#dictionary-conceptual-definition)

@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix :     <http://example.org/> .

:e1 a prov:Entity .
:e2 a prov:Entity .

:d1 a prov:Dictionary;
    prov:hadDictionaryMember [ 
       a prov:KeyEntityPair;
       prov:pairKey   "k1"^^xsd:string;
       prov:pairEntity :e1
     ], [ 
       a prov:KeyEntityPair;
       prov:pairKey   "k2"^^xsd:string;
       prov:pairEntity :e2

Tim doesn't like that prov:hadDictionaryMember isn't a subproperty of prov:hadMember, and that the dictionary Note doesn't use the Directed Qualification Pattern that is used throughout PROV-O. Instead, they reinvented terms that don't follow any pattern (b/c PROV-N couldn't handle it).

PML 3's current definition for a Map is "An associative array, an abstract data type composed of a collection of keys and a collection of values, where each key is associated with one value". So, our Map is a kind of prov:Dictionary that is also considered a prov:Plan. Since prov:Dictionaries have many more uses, I think we're justified in defining a pml:Map that specializes prov:Dictionary as a pml:Plan.

PROPOSE pml:Map subclassof prov:Dictionary, pml:DeclarativePlan (and thus prov:Plan)

PROPOSE pml:VariableMapping no longer subclass of pml:Map (instead, just subclass of pml:DeclarativePlan).

  • We agreed to modeling "prov:used [ a pml:VariableMapping, :A; prov:value 4 ]"
  • Having a pml:VariableMapping as a prov:Dictionary would lead to something like "prov:used [ a prov:Dictionary; prov:hadDictionaryMember [ a prov:KeyEntityPair; prov:pairKey "A"; prov:pairEntity [ prov:value 4 ] ] ] ."

Belief and Trust remodel

Approach is to reuse the Directed Qualification Pattern that PROV uses. Create an unqualified binary relation pml:believes, then permit qualification of it using pml:qualifiedBelief, pml:Belief, and prov:entity in the same way that PROV qualifies any of its unqualified relations.

  a pml:Information, prov:Entity;
  prov:value "Dinosaurs still roam the earth.";

   a prov:Agent;
   pml:believes :dinosaurs_still_roam_the_earth;
   pml:qualifiedBelief [
       a pml:Belief;
       prov:entity :dinosaurs_still_roam_the_earth;
       what:goesHere .95;

The property what:goesHere describing the Belief above could be prov:value, up:assertionConfidence, or up:contentConfidence. (See http://www2013.org/companion/p167.pdf for up:):

  • prov:value provides "direct representation" of the pml:Belief, but the value ".95" doesn't seem to cover enough of the Belief. It's too ambiguous, so we wont' use it.
  • Still waiting to here back from Tom on which of assertionConfidence and contentConfidence is appropriate.

The same pattern can be used for trust: the unqualified property pml:trusts, then permit qualification of it using pml:qualifiedTrust, pml:Trust, and prov:entity. The same property what:goesHere can be reused for Belief and Trust (and, any other weighting). The prov:entity is always used to indicate the trustee regardless of the type of trustee. If the trusted Entity happens to be a prov:Agent, then it will be typed as such.

:sally a prov:Agent .

   a prov:Agent;
   pml:trusts :sally;
   pml:qualifiedTrust [
       a pml:Trust;
       prov:entity :sally;
       what:goesHere .95;

QUESTION: Is Trust a Belief? And, if so, is that worth modeling? Belief is by Agents of Information, Trust is by Agents of Entities. To warp Trust as a Belief is to say that an Agent believes the Information that an Entity will (likely) maintain a condition in a future situation. And I think that's too intricate to bother modeling at this point.

PROPOSE: Add pml:believes domain prov:Agent, range pml:Information

PROPOSE: Rename BeliefElement to pml:Belief as a qualification class: Belief subclass (exactly 1 on prov:entity), (prov:entity allValuesFrom pml:Information)

  • This implies that we deprecate hasBelievedInformation and hasBelievingAgent

PROPOSE: Add pml:qualifiedBelief domain prov:Agent range pml:Belief

POLL: FloatBelief subclass Belief min 1 up:??Confidence

POLL: FloatTrust subclass Trust min 1 up:??Confidence

PROPOSE: deprecate FloatMetric

PROPOSE: Add pml:trusts domain prov:Agent, range pml:Entity

PROPOSE: Rename TrustElement to pml:Trust as a qualification class: Trust subclass (exactly 1 on prov:entity)

  • This implies that we deprecate hasTrustee and hasTrustor


Meeting Preparation

Around the room

* Add a section for yourself 2 hours before meeting.
* Mark any discussion point that you would like to raise during meeting (with DURING MEETING). 
* Otherwise, assume that others will read the rest before meeting. 
* Also, please be considerate and read others' discussion points before the meeting starts.









  • nsf smart health proposal will have significant provenance play for sources of data. proposal preparation and doc appts dominating lately.
  • jefferson project work restarting next week


Discharge (Refuation)

Deborah happy with the pml:Refutation activity/plan, pml:wasNegatedFrom (including name, since no good alternative)

Design and example on last meeting notes.


Mapping spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0ArTeDpS4-nUDdFdBYkRUQ0hvUWFpTy1ObjlZSTJEaXc#gid=0


comment on InferenceStep's fromAnswer property: "the root node set that answers the specific query but not necessarily the present nodeset that hosts this inference step."

Patrick: it seems to be the wrong direction. "from" and "led to". Tim: We've changed the domain/range and the restructure.

The need was to tying an intermediate step to the final step.

We're not just "renaming" the fromAnswer, we're restructuring its domain and range (e.g. from describing an Activity to describing an Entity). The new design addresses the original requirements but uses a different structure.

Answer is a bridge from the Question to all of the intermediates that led to the Answer.

CONSENSUS this is fine.

Map vs Dictionary

Variable mapping examples: http://inference-web.org/iwbrowser/NodeSetBrowser?w=900&mg=1&st=Dag&fm=English&url=http%3A%2F%2Finference-web.org%2Fproofs%2Ftonys%2Ftonys_2%2Fns8.owl%23ns8

Input string: "TonysSpecialty is a ?x when every CRAB is a ?x"

from "?x"
to "http://iw.stanford.edu/enginesdoc/jtp/script-data/tonys.daml#"

Output string: "TonysSpecialty is a "http://iw.stanford.edu/enginesdoc/jtp/script-data/tonys.daml#" when every CRAB is a "http://iw.stanford.edu/enginesdoc/jtp/script-data/tonys.daml#""

from "?x" 

Output string: "TonysSpecialty is a SHELLFISH when every CRAB is a SHELLFISH"

Example 2:


A pile of maps, that needs to be done in a certain order to handle dependencies.

?t = ?when 
?person = |Ramazi| 
?where = |SelectGourmetFoods| 
?object = ?where 
?f = (|hasOffice| |Ramazi| ?where) 
?when = |April_01_2003|

sometimes variable names need to be rewritten, e.g. when two expressions use the same and are then combined to a more complete expression.

This swaps the need for mapping from URIs to literals -- the OPPOSITE.

prov:Dictionary only maps literals to entities.

pml:Map to handle the 4 cases:

  • pml:fromLiteral
  • pml:fromEntity
  • pml:toLiteral
  • pml:toEntity

qualify prov:hadMember


  • TODO: Tim make this modeling.
  • TODO: Cynthia to find examples of belief and trust (and ask Paulo)
  • TODO: group to review Belief and Trust model proposals.
Facts about IW Meeting 2013-10-10RDF feed
Date10 October 2013  +
Personal tools