IW Meeting 2012-08-24

From Inference Web

Jump to: navigation, search


Meeting Information


  • Administrative
    • Patrice accessing IW wiki
  • PML 3 issues to discuss:
    • Past tense?
    • Proposed Modules:
      • PML-base
      • PML-proof (PROV-EN?)
      • PML-IR (PML for Information Resources)
      • PML-BIO (PML for biomedical provenance)


  • Tim
  • Jim
  • Deborah
  • James
  • Patrice


  • Paulo
  • Patrick


Jim reviewed two design drafts in PML 3: pml:hasAntecedent and Activities as Plans. The feedback on both designs is that they are not complete enough for an external reader to approach and need to include background material and motivation. The drafts will be updated at:

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.



  • FUSE Storyboarding (Due 8/31).
    • Reviewing trace data from BAE to determine additional drilldown approaches needed for provided indicators.
    • Working with Amar to develop Virtuoso-based demo for SPARQL-backed drilldown.
  • Developing taxonomy set for data generated by FUSE.
    • Data in certain taxonomies (e.g., percentage figures) will derive from others (e.g., extent figures).
    • Will be referenced by summarization module to generate concise evidence views.

Provenance example for FUSE: - Assume the existence of a data point GrowthOfResearchers, which measures growth of researchers from 2001-10 for DNA Microarrays - GrowthOfResearchers is derived from a ten year time series of ResearcherCount data points. - In turn, these ResearcherCount data points are derived from listings of author entries (with info such as Name, Affiliation, etc.)


vaca! :-)


vaca! :-)


Gave Jim some feedback on the write-up of the discussion of “Plans as Classes of Activites”, in the process looked over some PROV properties discussed in the example.


  • fuse storyboard focus - james and amar are doing most of this this week while cynthia is on vacation
    • cynthia having troubles querying a virtuoso endpoint.
    • Tim: this is usually done with an HTTP request using the SPARQL standard.
    • James: <something about webdav and javascript>
  • papers - escience accepted, hicss accepted, linked science with han accepted, sati with jim and jeongmin accepted, waiting on citizen science paper info from iswc, fuse iswc poster/demo notification should come today
  • return to discussion with jim on pml / prov connection via subclassing of used
  • tim will start working with a datanet SEAD effort with a grad student (yue robin liu)
    • Ram Prasanna Govind Krishnan has also contacted Tim about SEAD
    • nat center earth-system dynamics NCED


  • No progress made on provenance related projects in the past week.
  • Meeting with Stephan today to go over SPCDIS
      • deborah is very interested in notes and comments, read over the Final Review notes on the drupal page, etc...
  • Writing up idea and use case for provenance capture within data access software OPeNDAP


What's ahead of me:

  • Finishing out the new cross reference code for PML 3.0's HTML (porting from PROV-O)
  • More plunking - accessing more instances, loading to triple store, doing analysis.
  • More exemplaring for PML 3 (____this task can be shared by others____)
  • More PML 3 OWL modeling tweaks and annotations to support documentation.
  • PML 3 HTML narrative

Outstanding Items

Today's discussions


Jim: doing proof-theoretics in. Two parts. … extending prov:used so that ALL  generated outputs are derived from used entities. … adding a material link between the outputs and inputs. … e.g. two specimen halves are NOT “derived” from the scalpal, but the scalpal is still prov:used. … PML 3 gives that more specific tie. … proof theory needs inference steps and the method used to produce the conclusion. … need to do derivation provenance and processual provenance. … when you use pml:used, you know there was derivational activity.


Deborah: Paulo to return on Monday. Coordinate phone meeting via cc Deborah.

Patrice: recap?

Jim: prov:hasAntecedent is a new property. Anything generated by an activity

(Tim: I think the scalpal and one specimen would be a good example)

:specimenX a prov:Entitiy.
:scalpel a prov:Entity.

# The cut activity:

:specimenCutEvent a prov:Activity;
 prov:used :specimenX, scalpel.

#  outputs from cut:

:specimenX.1 a prov:Entity;
 prov:wasGeneratedBy :specimenCutEvent;
 prov:wasDerivedFrom :specimenX.

:specimenX.2 a prov:Entity;
 prov:wasGeneratedBy :specimenCutEvent;
 prov:wasDerivedFrom specimenX.

specimenX.1 and specimenX.2 were derived from specimenX, but not the scalpel. The scalpel was used to cut the specimen in half, but no user who would be making this provenance graph would ever say that the specimens were derived from the scalpel, even though you could make a proof-theoretic claim that it was. Not all provenance is proof-theoretic.

:specimenX a prov:Entitiy.
:scalpel a prov:Entity.

:specimenCutEvent a prov:Activity;
 pml:hasAntecedent :specimenX;
 prov:used :scalpel.

:specimenX.1 a prov:Entity;
 prov:wasGeneratedBy :specimenCutEvent.

:specimenX.2 a prov:Entity;
 prov:wasGeneratedBy :specimenCutEvent.

Inference based on prop chain using pml:hasAntecedent:

:specimenX.1 a prov:Entity;
 prov:wasDerivedFrom :specimenX.

:specimenX.2 a prov:Entity;
 prov:wasDerivedFrom :specimenX.

Patrice: When introducing a new property, spell out what you mean by it. If a subproperty, mention. Bring existing explanations into narrative. Domain, range, examples. Need to bring non-PROV audiences into this.

Deborah: Same suggestion. references Zednik’s proposal.

TODO: Tim and Jim to redraft this design.

Tim: Paulo wants to close the list of inputs. PROV lets you add any number of additional “inputs” later on, but we need to know an application of an inference step is ONLY two antecedents.

Jim: NUNA issues with more than one antecedent.

Deborah: with these bindings on these variables, I could apply this inference rule to obtain this conclusion. … breaking sufficiency conditions in the past.

Jim: why not specify the activity as requiring X antecedents.

prov:Plan as a class of Activiities:

It is possible to mark successful the execution of a plan by an activity. This can be done by making the plan also be a class that is a subclass of prov:Activitiy. A successful activity would belong to the class defined by the plan. Here is an example using Modus Ponens (in TTL):

 logic:ModusPonens a prov:Plan; owl:Class;
   rdfs:subClassOf prov:Activity.
 :mpAct1 a prov:Activity, logic:ModusPonens.
   prov:qualifiedAssociation [ prov:agent :Jim; prov:hadPlan logic:ModusPonens];
   prov:wasAssociatedWith :Jim;
   prov:used [a prov:Entity, logic:ConditionalStatement; prov:value "X is a man => X is a mortal."];
   prov:used [a prov:Entity, logic:Statement; prov:value "Socrates is a man."].
 :mpConclusion a logic:Statement, prov:Entity;
   prov:value "Socrates is a mortal.";
   prov:wasGeneratedBy :mpAct1.

The core of this technique is that Modus Ponens is both an instance of plan and also a class. All instances of Modus Ponens are also activities. mpAct1 is an activity and an instance of Modus Ponens, and was associated with Jim, who had the plan Modus Ponens. The activity used a conditional statement, "X is a man, => X is a mortal." and a statement "Socrates is a man."  to generate a statement "Socrates is a mortal." Because the activity was an instance of Modus Ponens, and Jim had the plan of Modus Ponens, we can determine that the plan succeeded. Conversely, if mpAct1 was an instance of the complement of Modus Ponens, we could determine that Jim's plan failed. Similarly, if the plan were to be an instance of a subclass of Modus Ponens, for instance, a particular Forward Chaining algorithm, we would still determine that Jim's plan succeeded because mpAct1 would be an instance of Modus Ponens by subsumption.

While PROV's Plan is something of intent, we use OWL 2 punning to extend it to something which has also occurred. This provides us with several advantages:

  1. It is possible to directly query for activities that follow certain plans, and follow the inheritance hierarchy of it. For instances, more abstract plans, such as modus ponens, can be super classes of more specific algorithms, such as forward chaining, or particular implementations, such as the forward chaining implementation from the Jena rule inference engine.
  2. It is possible to express when an activity doesn't go according to plan, by expressing a disjoint class of the plan of an agent.
  3. It is possible to partially define a plan in terms of the provenance it will produce as OWL restrictions on the Plan-as-class.

This third advantage can be shown by extending the modus ponens example (in Manchester Notation):

 Class: logic:ModusPonens
   SubClassOf: pml:InferenceStep, prov:Activity
           prov:used exactly 1 logic:ConditionalStatement 
       and prov:used exactly 2 logic:Statement
       and prov:used only logic:Statement
       and prov:generated exactly 1 logic:Statement
 Class: logic:Statement
 Class: logic:ConditionalStatement
   SubClassOf logic:Statement

We are defining modus ponens by stating that it takes two statements, one of them being a conditional statement, and produces another statement. This obviously isn't a full definition of ModusPonens, but it does define it as a black box, in that it defines what inputs and outputs can be expected.

Patrice: what you can query, derivations resulting from this modeling. Explain punning.

Activity conformsTo [ a Plan ] .

Jim: only works for success, not for failure or intent.

Patrice: what inferences does this modeling provide? Then others can provide alternative approaches. … referencing two things with same label is confusing

Jim: but punning is built into OWL.

Facts about IW Meeting 2012-08-24RDF feed
Date24 August 2012  +
Personal tools