IW Meeting 2011-02-03

From Inference Web

Jump to: navigation, search


Meeting info


  • Tim, Deborah, Li
  • Stephan
  • Geoff
  • Cynthia
  • Jim


(note, last aggregation of agenda items was 2011-01-27; Tim will review and incorporate)


Proof Combining

  • Cynthia has first results from integration, but needs to analyze them.
  • Geoff still has to review the results.

Toy AB example (2) will help evaluation before the larger (100s) set theory examples.

TODO: Cynthia to make web page of results and send to Geoff - Geoff will review. TODO Geoff review on tues? and send out results next - go to set theory PXTP workshop proof exchange for theorem provers - http://cade23.ii.uni.wroc.pl/call-for-workshops-and-tutorials/

Cynthia questions need for "false" cases. Geoff thinks they were/should (?) be excluded. Geoff: OK to exclude.

Layered PML

Tim reviews the four components of Layered PML.

Li: WDOit is also input, the DL sparql ontology. Paulo says it covers different area (workflow), not PML. e.g. input and output is workflow and not provenance.

Tim's description of "provenance concepts" component.

  • not just FOO
  • James' extension for annotations
  • Nick's VisKO
  • Stephan's domain-specific integration.

TODO: tim add PoMELO

NOTE: active vs. inactive work.

Jim presents conceptual interoperability


CaBIG is trying to map logical and conceptual models to BRIDGE. CaBIG has CDE (common data element) - a reference to UML class/attribute/association

TODO: Tim to review Jim's email and provide feedback.

domain models => provenance models => domain models

Logical models: e.g. OWL models used to describe a domain.

Conceptual model is an annotation on a Logical model. Making a concept for every class/attribute/property in the logical model.

class/attribute/property  :concretizes a concept/qualit/relations

mapping to a common vocabulary (e.g. CaBIG using NCI Thesaurus)

NOTE: page three fig 1 could benefit from a visual layering distinguishing the domain model and the conceptual annotations. -Tim

minting the conceptual layer appears to be redundant, but

Diagnosis is an owl:Property. nci:Diagnosis

SUGGEST: add default namespace: :Diagnosis, and cmo namespace cmo:concretizes to clearly distinguish

THREE layers:

  • local domain logical model,
  • it's conceputal analogue, and the
  • domain-independent conceptual vocabulary.

Li: skos:broader (domain and range is skos:Concept)

Diagnosis is an owl:Class
Diagnosis_Concept is a skos:Concept
conretizes is the link from the logical model, domain NONE range is skos:Concept.

Jim: actually a pun; nci:Diagnosis is both the instance of skos:Concept AND the actual owl:Class.

concretizes is an AnnotationProperty.
concretizes is link from Logical Layer to Conceptual Layer.

CMO - conceptual modeling ontology

Diagnosis is a property

NOTE: has_domain is ACTUALLY rdfs:domain - make that clear.

Deborah suggests prepending :has*

TODO: is CMO available?

Deborah: owl:Property as classes b/c of UML restrictions on inheritance.

Deb: Concept is NOT equiv to class, it is the abstract NOTION? Jim: yes.

all owl:Classes have concepts, but not all skos:Concepts have owl:Classes.

Li: can use owl, uml to model same concept. Li: McCusker defined mc:Diagnosis (as skos, uml, owl)

Jim: important to draw distinction between classes and concepts.

Jim: different levels of description for information models.


Li: "McCusker diagonals"? -Tim DONE ask for clarification. (Diagnosis)

Jim: providing a level of equivalence that is more nuanced than owl:sameAs.

Li: Why not just keep them separated? Thesis would be simpler if saying there are 3+ around, now I have my own vocab to connect them b/c they are already defined.

Jim: NCI model already exists: nci:hasDiagnosis. Need relationship to common vocablary. this conceptual model provides that connection.

Li: which triple is contributed from own brain? Jim: lists them. (tim: TODO: make this clear in the diagram - which came from where?)

Li: when saying concretizes, linking from your own model to SKOS? Jim: no.

Li's "DIAGONALS" -> Diagnosis.

TODO: ask Stephan how this relates to integrating domain models with PML.

CA-tissue is a logical model.

TODO: Tim add diagrams and review to table for provenance concept cell

Li: don' tneed to say concreteize b/c know it is an owl:Property and knows domain and range and can infer that the concretize relation is there. Li: concretize relation is from owl:ObjectProperty to mccusker concept. Li: if you can enumerate domain of relation, it can be inferred from domain and range. Jim: inferred from what? Li: adding extra layer. any owl:Class has a related concept. then relating that concept with skos:broader. Li: we can use DL - borrow it. Jim: :hasDiagnosis is an owl property. Li: can define class that is object of :hasDiagnosis Li: JIm: modifying the logical model, not the conceptual model. Jim: the logicalmodel is an info model that exists in a partiula form: RDF, RDFS, OWLF ULL Jim: ocncptual model is set of skos conepts an drlations to a given vocab that exists from exitsting model. cna predate, can be used to analyze the logical model.

TODO: Jim answer why it can't be just solved at the logical model. A: what bout relating a OWL class to a Object Proeprty or datasetye property? Tim: what about being able to span OWl to UML? Jim: yes.

Jim: e.g. NCI doens' thav overarching vocab for UML

Tim: does Jim's work help Stephan's domain model integration with PML? Stephan: view domain model as owl ontology (observation ontology) connection points from domain model are simple b/c not a provenance model. has process or procedure from O&M. How to connect?

PML (provenance domain model) & domain model integration, not integrating similar models, but models that define different domains - usually means the overlap is not extensive and overlapping properties/concepts are fairly simple in at least one domain model.

TODO: Stephan to reflect on how Jim's work can contribute to what he needs.

Deborah likes NOTION instead of CONCEPT. Deborah; Logical description is one realm/layer and notion being another. LEAVE aside whether it's encoded as OWL or SKOS.

Li: regarding connections. Li: this is an ontology mapping issue. there is no objective mapping; nothing can be objective (it is subjective). Li wants reification to map one concept to another instead of introducing ONE triple so you have provenance of who made assertion. Li: are we doing ontology mapping solution? Li: to represent mapping, can you use reifications? Jim: e.g. concretizes is a direct assertion. (keep relation straightforward) when moving data b. simple search for mappings. Jim: can document relationship on the types/qualities. can have annotations on ontology as whole. (named graph, or associated ontology)

can't [] concretizes b/c of an annotation property.

Tim to Li: why does asserting it prevent you from reifying it?

Li: if you want a larger community, you need to reify it.

Deborah: this work needs to be motivated. Needs to be distinguished from contending approaches. need to define concretizes and value needs to be shown.

Li: you are using personal experience to build mapping.

Deborah: Goal is good and important to interopete across vocabs. Communities will want to encode in variety of paradigms (OWL, UML)

Li: we need a collaboration community.

Li: how much knowledge to throw in? Another model? keep simple.

Li: "adheres in relation" is an extra model that comes from someone else.

Jim: take away: simplify terms so it is consumable.

Deborah: try existing infrastructure (e.g. why NOT using reification)

Li hates RDF reification, loves non-RDF reification.

TODO: Jim clearly distinguish the layers in ALL examples.

TODO: Jim be explicit and clear of what is a property, what is a class, what is a concept.

TODO: Tim to exercise Jim's conceptual modeling ontology for the incubator group's current vocab mapping.

(reified triples can be asserted using property chains)

Wrap up:

  • Jim should summarize comments and follow up.

Stephan brought up listing of inferences for PML.

CIRO, researching provenance inferences. XML based standards. - why move away? what can reasoning give them, since XML can't.

Stephan: do we do any real inferences? are we using the ontology to actually do inference.

Stephan: OPM has some (transitive properties) for lineage. can find relationships among things not explicitly stated. Property chains and transitive properties.

Deborah: URL reference? A Formal Account of the OPM http://eprints.ecs.soton.ac.uk/21819/ -- Inferences defined in Section 4 "Inference in OPM graphs"

TODO: we need to do something like this for PML.

Stephan: PML's documenation of how inference is used is needed.

(T: UTEP's SPARQL ontology)

subproperty (hasContent and pmlp:hasUsageQueryContent are only two Tim sees.) class hierarchy.

Li about proof combining.

TODO: are there ANY real world connections among Justifications? Or do they all just encode their own.

What is provenance reasoning? Stephan says none.

can find evidence for a conclusion.

Stephan: proofs vs. provenance.

Li: combine and compare are sisters. need same technology to do both.

Li suggests incremental enhancements to Stephan. add links across provenance that you created. lets you combine, compare.

Stephan: they don't' care about combining. They care about inference. What provenance reasoning can we get? Stephan: we don't have reasoning for provenance, just for consistency. Stephan: is combining a tool or reasoning?

Li: we can make service available.

Li: 1st: if have prov trace, verify if each step is correct (manually). program for automated validation. proof validation is first thing we want to give them. we had work on ppdl - that supported automated validation if inferences were specified in a formal manner

Li: 2nd:

WaterML has restful service that validates their format. Stephan is basing PML validator on that.

Stephan: what OWL reasoning can expand provenance inferences?

Cynthia: SPCDIS search - given conclusion of proof, what are leaf nodes and their provenance. have list.

Stephan: what value do we get from OWL reasoning w.r.t. more provenance value add?

Deborah: What validations should we be doing?

Deborah: How are they ahead? Stephan: validation services that return useful error codes that check through model on explicit assumptions as well as implicit assumptions of tools.

Stephan: valid OWL breaks the tool b/c of assumed disjoint in tool but now explicit in ontology. (e.g. NodeSets and InferenceSteps as same instance) (e.g. Document can't be Information according to the tool) (the conclusion needs to have Information as conclusion.)

what about [] a Info and Document?

Validator should check for implicit assumptions. Programmatically callable from RESTful interface.

Approach: RESTlet a java framwork. Can deploy via Tomcat on escience or provenance machines.

pluggable tests

Jim switched from RESTlet to Wink.

DONE: Tim to send link to UTEP's ontology to make SPARQL queries easier (property chains) http://trust.utep.edu:8080/sparql-pml/ http://trust.utep.edu/members/jarora/PML-SPARQL.owl

Action Items

  • Cynthia web page results
  • Geoff to review Cynthia's results and report back
Personal tools