PIL OWL Ontology Meeting 2011-11-14
- previous meeting
- date: 2011-11-14
- time: 9am PT, 12 noon ET, 5pm UK
- via Zakim Bridge +1.617.761.6200, conference 695 ("OWL")
- wiki page: http://www.w3.org/2011/prov/wiki/PIL_OWL_Ontology_Meeting_2011-11-14
- titan page: http://titanpad.com/JVi8UTDJr7
- next meeting
- Tim (MUST leave to be on time to a 13:00 meeting)
- Daniel (in Seattle)
== Agenda == 1. Finalize the text changes and review the new classes and properties in the html document 2. Updates on addition of new figures and changes to existing ontology schema 3. Changes to the crime.owl file to reflect changes in prov-o 4. Feedback on the formal semantics section from James
Khalid asks if there was wish to move the meeting to one hour earlier. Not sure.
Qualified involvement approach
Satya has made changes. Need to update the class hierarchy figure.
Section 3.1 diagram must be updated. EntityInRole to be removed. QualifiedInvolvement and children to be added.
Diagram for new properties - section 2.3.18 (?), 2.3.19, 2.3.20, 3.2.21, 3.2.22
Khalid: Move ..(?)
Satya: To break down ontology into two different parts.
Khalid: Figure for usage/generation etc. that are (?) - we won't have a single figure of all object properties because it gets very complex. Instead we'll have to additional figures, explaining how Usage/Generation/PArticipation/Control are modelled.
Satya: OK, so figure 3.5 without EntityInRole
Khalid: But with QualifiedInvolvement - but not complete overview of ontology. The subclasses of QI shown in separate figure.
Satya: OK, 3.5 without EntityInRole - 3.6 a new QualifiedInvolvement section.
Satya: Khalid working on various diagrams. To offload/help, Stephan can help. Satya needs to addd text for some examples..
Satya: Can Stephan Work with Tim and Khalid on new 3.6 QualifiedInvolvement and subclasses, relation to Entity and ProcessExection, plus hadRole and a Role.
Satya: Just a new 3.6 overview of QualifiedInvolvement
Tim: Will base diagram of 3.5
DONE: Khalid send Tim the hg URL for the diagram in 3.5
(pngs for each layer saved in same folder) TODO: Tim and Stephan new 3.6 QualifedInvolvement-specific diagram. Will base it on existing diagram in 3.5
Satya: Almost done with section 4.1 as well - will go through 4.2 afterwards.
Stian: Need to update 4.2 EntityInRole
Satya: NEed to cut down on RDF.. 4.2.5 split it into different sections.
Stian: Would have read easier in different sections if it was turtle. (http://dvcs.w3.org/hg/prov/raw-file/49da137f8bf2/ontology/examples/ontology-extensions/workflow/workflow.ttl ) Tim: +1 turtle for readability
Satya: Not using Turtle in HTML - but provide links.. need to clarify this later.
Satya: Section 5 - JAmes any feedback on formal semantics part?
James: Which sections?
Stian: 5.1, 5.2, 5.3
James: 5.1 and 5.2 look fine. Might want to say more on 5.3 inference roles that we assume hold - might want something more specific that lists these. Could kind of go from model to rules, or rules to the model. Don't need to do this, though. Should read through a copy of "RDF Semantics" and read it carefully! Had some minor questions on entailment:
James: In 5.3.5 Issue is listed what is in DM document. http://dvcs.w3.org/hg/prov/raw-file/49da137f8bf2/ontology/ProvenanceFormalModel.html#provenance-constraint-on-used-use-attributes
"Given a process execution expression identified by pe, an entity expression identified by e, a qualifier q, and optional time t, if assertion used(pe,e,q) or used(pe,e,q,t) holds, then the existence of an attribute-value pair in the entity expression identified by e is a pre-condition for the termination of the activity represented by the process execution expression identified by pe." This is ISSUE-124
James: Issue is still open. Can we enforce this constraint?
Satya: Paolo is on the call. PROV-DM is to cut down on all these constraints.
James: Is this somethin that can't be enforced?
Satya: Should we try to make these rules in the ontology, or are you moving to delete them?
Paolo: Some of them deleted.. Need a vote on removal on some constraints. After this, that's it. Constraints remaining, if they can be enfored with rules, that would be great. Some of them will go, but have to check which ones as they were not voted on in last WG call. Propose to postpone this for now.
Paolo: Will look at all constraints and see which can be enforced.
Paolo: What rules language are you using?
Satya: Rule interchange framework. (?) Rest code (???)
James: which constraints are still active - need to coordinate.
James: Text of 5.3.5 does not match issue text (in yellow).
James: To make it consistent for public release we should have fixed this.
Satya: Probably a copy-and-paste mistake.
James: 5.3.7 - not sure what this has to do with open world assertion - just an inference rule.
Satya: yes, understood, misled by "can be asserted" --> "cam be inferred"
Tim: there is a compact version and a "full version" of wasDerivedFrom:
Derivation Expressions (described in Section Derivation) express that an entity is derived from another. The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the process execution underpinnng the derivation, and relevant qualifiers qualifying the use and generation of entities. wasDerivedFrom(e2,e1) wasDerivedFrom(e3,e2) wasDerivedFrom(e4,e2,pe2,qualifier(port=smtp, section="attachment"),qualifier(fct="attach")) wasDerivedFrom(e5,e3,pe4,qualifier(port=smtp, section="attachment"),qualifier(fct="attach"))
Satya: Paolo, is this saying that such a PE should be asserted/
Paolo: Just claims that such a PE exists, you are not required to assert it.
Satya: OK, could make it a neccessary condition - but if this is not the intent then it would be covered by open world assumption
Stian: The PE exists - if it is asserted or not.
Paolo: If you want to assert it, then that is OK, you can say why you asserted it. Can explicitly mention the PE - but you do not have to make that instance.
James: so - if Prov-DM instance with wasDerivedFrom statement - that's fine on its own. It is also fine if there is a wasDerivedFrom with extra facts in it about the PE. From existence of wasDerivedFrom(A,B) you can infer that there was such a PE that generated entity B and used A. So it can be asserted, but does not change the meaning of the Prov-DM account.
Tim: Want to comment on this. It is fine that one entity is derived from another. If you find this statement - then you know there exists *some* process executions with some potential qualifiers that used something to generate the derived entity. You know it exists - but not neccessarily anything else (yet).
Satya: This is not possible to model as a rule
(Stian: Is this not something that is easy enough to model in pure OWL with someValuesFrom?)
I interpret 5.3.10 as the following FOL-like formula over PROV-DM:
wasDerivedFrom(e2,e1) ==> exists PE. wasGeneratedBy(e2, PE) && used(PE, e1)
ex:e2 a prov:Entity ; prov:wasGeneratedBy [ a prov:ProcessExecution ; prov:used ex:e1 ] ;
Maybe PE could be a fresh "blank node"??
Satya seems to be saying this constraint cannot be defined as an OWL rule. I guess the reason that "exists" can only range over URIs that already exist in the data set?
this is nothing magical - this is just like if a class has minCardinality 1 on a property - and you have such an instance of that class, you know that there is also that property statement with "some" value in the end.
Stian I will leave at 18:00 as well - so feel free to disgress as usual ...
It will just be a *** bnode which MIGHT be owl:sameAs some URI
- e1 prov:wasGeneratedBy [ <<-----
- THIS IS THE BLANK NODE
] <<---- .
THERE YOU GO WHAT IS THE F... URI FOR THAT?
This is fine (According to Satya's "rule", this is incorrect RDF): <purl.org/twc/id/person/TimLebo> owl:sameAs [ a foaf:Person; foaf:name "Tim" ] .
Blank nodes described here: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#unlabel
Role of process execution
Satya: To Come up with an example where both PE and Entity have roles. If qualifiedEntity and hadRole / qualifiedEntityHadRole
would we also have qualifiedProcessExecutionHadRole ?
Stephan: how can a process execution play a part in itself?
From: http://www.w3.org/TR/prov-dm/#example-prov-asn-encoding wasGeneratedBy(e2, pe1, qualifier(fct="save")) used(pe3,e2,qualifier(fct="load"))
Must go, sorry. -Tim
Tim thinks that Satya is trying to use composite ProcessExecutions to model Accounts.
Stephan: Always viewed roles as part or function an entity plays in a process execution. If a PE plays a role - then that implies a different PE - acting as an agent.
Stian: http://www.w3.org/TR/prov-dm/#expression-Control has roles as well for agents. (and a PE *might* be an agent)
I remember previously that we raised this point, i.e., an agent may be an entity, but Luc was opposed to it.
Let's just call it prov:hadRole and leave it as an issue.
- pe3 prov:hadQualifiedUsage [
a prov:Usage ; prov:hadRole :attachment ; prov:qualifiedEntity :e2 ]
- reads: "The usage had role "attachment"
Satya: Updating ProvenanceOntology.owl file for now - not Tim's prov.owl system
Stephan: Location on usage sounds like a qualifier. Location and time are both examples of qualifiers.
Satya: (?) to raise this in an email to the WG. No, Satya will send it.
On qualifiers. Agents.. on behalf of. Believe that this is also a qualifier.
- pe1 prov:hadQualifiedControl [
prov:qualifiedEntity :someEmployee ; prov:hadRole :Analyst ; prov:onBehalfOf :someOrganisation ; prov:hadLocation :someHouse ; ]
- someEmployee a prov:Agent .
- someOrganisation a prov:Agent .
Add a discussion point for onBehalfOf? Instead of replacing existing relations.
Satya: Section 3.. classes holding section. Properties holding part.
Properties Stian created for startedAt, endedAt, wasGeneratedAt, assumedRoleAt.
- e1 prov:wasGeneratedBy :pe1 ;
prov:wasGeneratedAt :t1 .
- pe2 prov:hadQualifiedGeneration [
a prov:Generation ; prov:qualifiedEntity :e1 ; prov:involvedAt :t2 ; ]
- Current constraint (which Stian, Khalid, and Satya don't agree with!!)
- means you can then infer
:t1 owl:sameAs :t2 :pe2 owl:sameAs :pe1
Stian: Would prefer to not have wasGeneratedAt and only include it in the QualifiedInvolvement (we dont have dangling prov:wasUsedAt etc - time is just a qualification just like role and location)
Stian: Some involvements like Usage/Control should be able to have duration - not just prov:(first)InvolvedAt.
(I would model prov:involvedAt as subproperty of time:hasBeginning) http://www.w3.org/TR/owl-time/#relations
leaving time:hasEnd as the opposite end - making the QualifiedInvolvement be an instance of prov:TemporalEntity (possibly a time:ProperInterval if the end is after the beginning - otherwise a time:Instant). )