PIL OWL Ontology Meeting 2012-04-16

From Provenance WG Wiki
Jump to: navigation, search

Meeting Information

prov-wg - Modeling Task Force - OWL group telecon


  • Tim (on phone)
  • Daniel (on phone)
  • Stephan (on phone, but aren't we all?) I can't know without asking.
  • Paolo (phone -- will join about 5.15 though)
  • Satya (also on phone)
  • Khalid (on phone)


  • around the room
  • pending-review
  • open issues
  • issue seeds
  • AOB

Around the room


  • 83 (explicitly state (define?) inverses?)
    • Dan: unless we have an explicit example that motivates inverses, avoid having them.
    • Stian: agree. if we have th euse case, we STILL should put it into a separate file. 
    • ... bad for interoperability (one uses one, another uses another)
    • Stephan: how so?
    • Stian: if we define both, then both will be used and we'll need to handle both in a query.
    • Tim: if we dont' _name_ the inverses, then people will use differnet names for the inverse.
    • Stephan: property chains? to create proper path. Just trying to find a use case.
    • Satya: ??
    • Stephan: a - c via b (may need a specific direction to create the chain)
    • Satya: if does not exist, does not prevent you. you can define the inverse property in the property chain.
    • PROPOSED: define inverse that aren't motivated in a separate, and include as an appendix of the PROVO HTML. ACCEPTED.
      • Satya:  this sounds like a good approach - will not clutter up existing ontology. One caveat is resolving inverse properties requires use of a reasoner 
      • Stian: we'll need to maintain the correspondence.
      • Khalid: how many inverses? http://dvcs.w3.org/hg/prov/file/tip/ontology/components/inverses.ttl 
        • Tim: (we'll continue the "only when motivated" approach)
  • Luc 84 (ext:wasGeneratedBy), 262 (prov:qualified), 263 (hadUsage),  CLOSED
  • Luc 268 (2 ontologies) . In his email, Luc says: Regarding ISSUE-268, irrespective of the two-level ontology suggested originally, it would be

good to decide whether there will be an attempt to define constraints (such as in prov-dm-constraints) in a separate ontology (or even the current one, if it's feasible) or in some form of rule language, or other.

    • postponed.
  • Stian 123 (hadParticipant)
    • TODO will review. - Thanks!
  • Stephan Z 259 (temporalExtent; now {started,ended}AtTime, atTime and atLocation) (TODO: will be done by end of day)
  • Stephen C 277 (prop chains), 320 (rename quotation)
    • TODO: Satya to provide description how to use inverse proeprties when not actually named in orig ontology.
  • Jun 305 (last review pass)
    • postponed.


  • 117 from Luc on "emphasis on extension" - CLOSED
  • 119 from Paul on "reconcile with vanilla RDF" - CLOSED
  • 128 from Paul on "file path is not a location" - I disagree
    • latest DM: A location can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column. As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, and so forth. 
    • PROPOSE to add file path AND office cube attributes to PROV-O expanded example
    • atLocation :column_1 . 
    • atLocation <file:///Users>. 
    • atLocation :building_34 . 
    • atLocation [ wgs:lat 45, wgs:long 45 ] .
    • Daniel: if Paul doens't like non-geo, then he should raise issue on DM.
  • using strings http://www.w3.org/2011/prov/track/issues/248 (CLOSED) == http://www.w3.org/2011/prov/track/issues/222
  • 250 from Eric on prov-o html review - asked him to close (covered by other issues or address them)
  • 308 from Tim on "W3C style"
  • 338 from Tim (via Luc and others) on "prov:activity vs. prov:hadActivity" naming conventions.
    • Tim: is this diffuclt to understand?
    • Khalid: yes.
    • Stephan: yes
    • Daniel: we're using both.
    • Stian: Early resolution. verbs in past tense form. e.g. wasGeneratedBy instead of generator. But PROV relations can be different from PROV-O properties.
    • Tim: anybody to tackle this?
    • Tim: how do we make it clearer?
    • Daniel: hadActivity domain is Derivation or Responsibility and Involvement.
    • postponed. not taken up.

issue seeds

  • RL and DL variants POLL: are we interested in doing this?
    • Tim: do this?
    • Stian: interested, baring some time constraints. Jun may, too.
    • Khalid: do this now?
  • Relaxing the RL constraint (a bit)
    • Ivan: "If the ontology is really more readable that way, than this should certainly be of a higher priority than a strict adherence to OWL RL."
    • "RL Violations" section in PROV-O HTML that lists what axioms exist that are not RL.
    • Stian: is RL++, who are we leaving otu by doing that? Do the tools fall over?
    • Tim: Ivan says RL tools "gracefully move on"
    • Stian: HasARoleClass intermediate.
    • Tim: shifted paradigm: ONLY RL to just how much nonRL?
    • Khalid: if there are RL violations, were do they occur? in Involvements, since the direct properties.
    • ... if you want more than direct relations, then you lose RL.
    • Tim : RL serves as a baseline - PROV-O should be measured as (PROV-O - RL) = delta.
    • Daniel: why hadRole Invovlement AND Responsiblity or Derivation 
    • Tim: backwrad compatibility.
  • prov:involvee (aka prov:object)
    • Daniel  (I'm okay with that name, but I'm aweful at names :) )
    • Tim: would prov:object be better? I dont want to expose reification too much...



Did not get to


issue seeds