Warning:
This wiki has been archived and is now read-only.

PIL OWL Ontology Meeting 2011-09-19

From Provenance WG Wiki
Jump to: navigation, search

Meeting Information

prov-wg - Modeling Task Force - OWL group telecon

Agenda

  • Roles

Attendees

  • Paolo
  • Tim
  • Satya
  • James
  • Daniel
  • Stian
  • Khalid
  • Luc

Discussions

Roles

Satya's Sept 16th http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0163.html example on how roles can be modelled:

 e1 wasGeneratedBy pe1  e1 wasGeneratedOnPort p1 # This is an example "extension property", a subproperty of wasGeneratedBy  e1 hasOrderOfGeneration 1

Conceptual model vs. Logical model (OWL)

Luc: ontology should reflect conceptual model. 

Paolo: conceptual model will likely be difficult to encode in ANY logical model (OWL included).

Luc: Interoperability and interchange.  need to interchage with apps that are not semantic web (but can load RDF triples).

we need a lightweight schema - which with be OWL. applications that are NOT OWL-aware must still be able to consume the provenance assertions.


characterizingProperty

Q: What is the difference between characterizing properties and other attributes? How should we separate between them (if at all) in the RDF/XML encoding? (who asked this?)

  • as an aside, we need to distinguish among them in the RDF Abstract Model (independent of serialization)


(WHY should we separate them?) -Tim


Conceptual document says

An instance of an entity expression, noted entity(id, [ attr1=val1, ...]) in PROV-ASN:

contains an identifier id identifying a characterized thing; contains a set of attribute-value pairs [ attr1=val1, ...], representing this characterized thing's situation in the world. The assertion of an instance of an entity expression, entity(id, [ attr1=val1, ...]), states, from a given asserter's viewpoint, the existence of an identifiable characterized thing, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two events in the world.

Possible Solutions

Tim thinks the discussions waver among the following three solutions:

  • SPARQL :entity ?p ?o   -- This just GETS  ALL of what has been asserted.
  • OWL minCardinality 1  -- This says WHAT YOU EXPECT from certain instances
  • owl:key   --- This says that two instances with the same values of the given properties are owl:sameAs
    • owl:key says that if two instances have the "same values" for each of those properties listed in the class'es owl:has_key , then they are the same individual -Stian


first cut

Khalid - it is :entity ?p ?o Luc - "probably [owl:key] is not the case"

James: I interpret Jim Myers' recent statements as indeed *requiring* that the asserted attributes (together with time interval information) form a key.  (I'm not sure if I agree with this though.)

ISSUE 89

Hi Luc, My responses are interleaved.

> So here they are: >entity(e1,[ company: "Toyota", model: "Corolla", identification="1a"]) >entity(e2,[ company: "Toyota", model: "Corolla", identification="1a", owner="tom"])  >entity(e3,[ company: "Toyota", model: "Corolla", identification="1a", owner="luc"]) 

ok.

>wasDerivedFrom(e3,e2)  (since e3 was bought by luc from tom)

This is also ok - this is what I meant in my previous mail (e1 and e2 can exist, but it should be explicit that e2 is e1 with additional "necessary" attributes.)

> But how does it work in an open world context, when there may be other assertions in your triple store, e.g. e1 hasColor blue. But the color property is >not one of the attributes  used in any of e1, e2, e3.

We make additional assertions that e1 hasColor blue etc. - I am not sure I understand the problem in adding these new assertions to existing assertions (the ability to add the new assertions is the "open world assumption").

Going back to your original mail: >The conceptual model defines an entity in terms of an identifier and a list of attribute-value pairs. It is indeed crucial for the asserter to identify the >attributes that have been frozen in a given entity.Currently, the ontology does not seem to identify these attributes.

If you define an ontology class called "Toyota Corolla Car" and define a set of "necessary" restrictions using attribute-value pairs then all entities that are asserted to be instances of this class must have those attribute-value pairs asserted for them. For example, for entity e1 to be instance of the "Toyota Corolla Car" class: 1. It needs to be a car (maybe inherited from the parent class "Car") - with a set of defined attributes like hasPart wheels, steering mechanism etc.  2. It needs to have an attribute called hasManufacturer and the value of this attribute has to be "Toyota" 3. It needs to have an attribute called hasModelType and the value of this attribute has to be "Corolla"

These "necessary" attributes have to be defined apriori by the ontology developer to create a specific class and this is not related to "open world assumption". If color is defined to be a "necessary" attribute then the asserter has to define the attribute for the entity instance and assign a value else it cannot be an instance of a "Toyota Corolla Car" (maybe "Blue Toyota Corolla Car" is more appropriate class for that restriction).

> To say that these attributes could be found by looking at all the properties for this entity does not work with an open world assumption. As above - the "necessary" attributes are not made optional by the open world assumption.

On a separate note (not related to open world assumption), we can have a set of "necessary and sufficient" conditions for a class that allows any entity instance to be "automatically" (by a reasoner) inferred to be a member of a specific ontology class (also referred to as "defined" class). 

Thanks.

Best, Satya

Person subclass of Breather

If I'm a person, I am breathing.


Are we expecting clients to expect ?

Tim: why does "characterizing" matter? Luc: http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0187.html javascript client


Ontology HTML updates

TODO: Tim instance data diagram. TODO: Tim 2.6 extension diagram