ProvRDF

From Provenance WG Wiki
Jump to: navigation, search

Introduction

13 May 2013 
This page is now frozen and will not be updated.  Please see the PROV-FAQ question about 
mapping between PROV-N and PROV-RDF for future developments on this topic.



14 Feb 2013
Note: this page was last edited 20 April 2012 and was only used by the 
WG while the PROV-DM and PROV-O were in flux.

Héctor Pérez-Urbina submitted to public-prov-comments@w3.org some notes similar to this page's material.


This document gives a draft translation from PROV-DM to PROV-O, and sketches how to go in the reverse direction (i.e. how to extract PROV-DM from a RDF graph that includes PROV-O data as well as possibly other RDF).

Guideline: We include all RDF assertions associated with a DM assertion, even if some of them wind up being redundant/inferrable.

Guideline: Optional arguments (including attribute lists) are in square brackets; if the argument is missing, we generally omit the corresponding RDF edges. (In some cases, not currently documented, an optional argument to a record corresponds to an unknown value that should be generated as a blank node; this remains under discussion.)

From PROV-DM to PROV-O

We define a translation from PROV-DM formulas to RDF conforming to PROV-O as follows.

Mapping coverage

http://aquarius.tw.rpi.edu/prov-wg/provrdf-owl-coverage shows the [mis]alignments among PROV-DM WD3, ProvRDF, and PROV-O.

PROV-DM

PROV-DM WD3

To see the ASN expressions mentioned in the PROV-DM WD3 page, run this command: 

curl -H "Content-Type: text/turtle" -d "<http://www.w3.org/TR/2012/WD-prov-dm-20120202/> a <http://xmlns.com/foaf/0.1/Document> ." http://sparql.tw.rpi.edu/services/datafaqs/util/wikitable-fol


PROV-DM WD4

ProvRDF will be aligned against WD4 very soon.

ProvRDF

LHS

The undersigned have reviewed DM WD3 and agree that all ASN signatures in WD3 appear as left hand sides of the rules shown on this page. Further, the rules here are in the same order as DM WD3 and no rules appear here without appearing in DM WD3.


  • Daniel Garijo (10-Feb-2012)
  • Tim Lebo (collections still missing) (13-Feb-2012)
  • James Cheney (basic stuff is here, collections/accounts is not) (16-Feb-2012)

The constructs are listed in an order that corresponds to the order given in PROV-DM WD3.

To see the ASN expressions mentioned in this page, run this command: 

curl -H "Content-Type: text/turtle" -d "<http://www.w3.org/2011/prov/wiki/ProvRDF> a <http://xmlns.com/foaf/0.1/Document> ." http://sparql.tw.rpi.edu/services/datafaqs/util/wikitable-fol

RHS

To see the classes and predicates mentioned in this page, run this command: 

curl -H "Content-Type: text/turtle" -d "<http://www.w3.org/2011/prov/wiki/ProvRDF> a <http://xmlns.com/foaf/0.1/Document> ." http://sparql.tw.rpi.edu/services/datafaqs/util/wikitable-gspo

ProvenanceOntology.owl

Components

The following values are used for prov:component annotations in the OWL file:

  • (1) entities-activities
  • (2) agents-responsibility
  • (3) derivations
  • (4) alternate
  • (5) collections
  • (6) annotations

Mapping goals

1: Maintain Entities and Activities principal subjects

Subjects of triples are more principal than objects of triples. Because Entities and Activities are the two principal topics of PROV-DM, the RDF mapping should prefer that Entities and Activities be subjects of as many triples as possible. In the case when the object instance is ALSO an Entity or Activity, the directionality of the triple should point to the Element that "existed earlier". For example, :activity prov:used :entity is preferred over :entity prov:usedBy :activity because the entity existed before it was used by the activity.

2: Avoid proliferating owl:inverseOf

Although every property could have an inverse, we choose one preferred direction to keep the model small and understandable. Providing all inverses could be done in a supplemental profile. One exception to this rule is prov:wasGeneratedBy's inverse: prov:generated, which is included because of goal 1. When an asserter is describing an Activity (a principal Element), they should be able to describe it as a subject. prov:generated is needed to do this.

3. Include _all_ resulting triples, including those resulting from inferences

4. Naming style for prov:entity prov:activity prov:agent is RESERVED

The naming style of prov:entity prov:activity and prov:agent is adopted from that of rdf:object. NO OTHER prov predicate may adopt this same style, so that the style clearly indicates _which_ predicate is referencing the object of the unqualified relation that the Involvement is qualifying.

So, predicates named quoter, quoted, generation, usage are not permitted. If we _are_ going to reference these things from an Involvement, the hadXXX pattern should be followed.

restate: Properties on Involvements which are a noun and match the desired range (e.g. entity, activity, agent) are reserved for the reification properties of an involvement?

Visual style

  • Tokens in a gray background have a scope local to the assertion (e.g. ":id").
  • Tokens in a light brown background exist in the provenance namespace (e.g. "prov:wasDerivedFrom").
  • Tokens in white background appear in existing namespaces (e.g. "sd:" == "http://www.w3.org/ns/sparql-service-description#", "a" == "rdf:type", "dcterms:")
  • Triples with gray text can be inferred with RDFS reasoning, e.g. superclasses/superproperties, however typing from rdfs:domain / rdfs:range are shown in black.
PROV-N sd:name Subject Predicate Object
asnExpression(id,e,a,t,[attr_1=val_1, ...])
==>  :a a prov:
 :e a prov:
 :e a prov:
 :e prov:  :id
 :id attr_1 val_1
...
 :id attr_n val_n

Partial mappings

The right hand side of the rules shown on this page are intentionally verbose. They are included to see the full ramifications of a DM ASN expression.

Note that if an argument is not provided in the ASN, the corresponding triples that require that value are NOT produced (unless they are required to link to other produced triples). This means that simple ASN assertions produce simple PROV-O assertions.

For instance, if in PROV-N we have simply wasGeneratedBy(e,a) rather than the full wasGeneratedBy(e,a,t,[attr_1=val_n, ..., attr_n=val_n]), then:

PROV-N sd:name Subject Predicate Object
wasGeneratedBy(e,a)
==>  :a a prov:Activity
 :e a prov:Entity
 :e prov:wasGeneratedBy  :a


However if time was also given, we will need to expand into an involvement:

PROV-N sd:name Subject Predicate Object
wasGeneratedBy(e,a,t)
==>  :a a prov:Activity
 :e a prov:Entity
 :e prov:wasGeneratedBy  :a
 :e prov:qualifiedGeneration _:id
_:id a prov:Generation
_:id prov:activity  :a
_:id prov:atTime t^^xsd:dateTime

Translating element records

PROV-DM Element

Issues:

Entity

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)


PROV-N sd:name Subject Predicate Object
entity(id, [ attr1=val1, ...])
==>  :id a prov:Entity
 :id  :attr_1 val_1
...
 :id  :attr_n val_n


Issues:

Account

  • (Incompletely) mapped to OWL
  • TODO: This needs some explanation

PROV-DM (eg) <math>\implies</math> [PROV-O] (eg)

PROV-N sd:name Subject Predicate Object
account(id, exprs)
 :id  :namedGraph a prov:Bundle
 :id  :namedGraph a sd:NamedGraph
 :id  :namedGraph sd:name  :id
 :id  :namedGraph sd:graph  :graph
 :id  :namedGraph prov:specializationOf  :graph
 :id  :namedGraph attr_1 val_1
...
 :id  :namedGraph attr_n val_n
 :id  :rec_1_subject  :rec_1_predicate  :rec_1_object
 :id  :rec_2_subject  :rec_2_predicate  :rec_2_object
 :id  :rec_n_subject  :rec_n_predicate  :rec_n_object 
sd:graph rdfs:subPropertyOf prov:specializationOf .


Issues:

  • attrs could go on either the Named Graph or the Graph - each is useful.
  • Need to outline typical named graph handling - the same graph spreads into different named graphs across the world.

Activity

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
activity(id, st, et, [ attr1=val1, ...])
==>  :id a prov:Activity
 :id prov:startedAtTime st^^xsd:dateTime
 :id prov:endedAtTime et^^xsd:dateTime
 :id  :attr_1 val1
...
 :id  :attrn valn


Issues (LHS):

Agent

  • Mapped to OWL


PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
agent(id, [ attr1=val1, ...])
==>  :id a prov:Agent
 :id a prov:Entity
 :id  :attr_1 val_1
...
 :id  :attr_n val_n



Person

  • Mapped to OWL
PROV-N sd:name Subject Predicate Object
agent(id, [ prov:type=prov:Person, attr_1=val_1, ..., attr_n=val_n])
==>  :id a prov:Person
 :id a prov:Agent
 :id a prov:Entity
 :id  :attr_1 val_1
...
 :id  :attr_n val_n


Uses before defined:

  • prov:type

Organization

  • Mapped to OWL
PROV-N sd:name Subject Predicate Object
agent(id, [ prov:type=prov:Organization, attr_1=val_1, ..., attr_n=val_n])
==>  :id a prov:Organization
 :id a prov:Agent
 :id a prov:Entity
 :id  :attr_1 val_1
...
 :id  :attrn valn


Uses before defined:

  • prov:type

SoftwareAgent

  • Mapped to OWL
PROV-N sd:name Subject Predicate Object
agent(id, [ prov:type=prov:SoftwareAgent, attr_1=val_1, ..., attr_n=val_n])
==>  :id a prov:SoftwareAgent
 :id a prov:Agent
 :id a prov:Entity
 :id  :attr_1 val_1
...
 :id  :attr_n val_n


Uses before defined:

  • prov:type

Note

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

  • Mapped to OWL
PROV-N sd:name Subject Predicate Object
note(id, [ attr1=val1, ...])
==>  :id a prov:Note
 :id  :attr_1 val_1
...
 :id  :attr_n val_n

Translating relation formulas

PROV-DM Relation

Generation

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
wasGeneratedBy(id,e,a,t,attrs)
==>  :a a prov:Activity
 :e a prov:Entity
 :e prov:wasGeneratedBy  :a
 :e prov:involved  :a
 :e prov:generatedAtTime t^^xsd:dateTime
 :e prov:qualifiedGeneration  :id
 :id a prov:Generation
 :id a prov:InstantaneousEvent
 :id a prov:ActivityInvolvement
 :id a prov:Involvement
 :id prov:activity  :a
 :id prov:atTime t^^xsd:dateTime
 :id  :attr_1 val_1
...
 :id  :attr_n val_n 


prov:wasGeneratedby owl:inverseOf prov:generated .
prov:wasGeneratedBy rdfs:subPropertyOf prov:involved .

Issues:

Usage

  • Mapped to OWL


PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
used(id,a,e,t,attrs)
==>  :a prov:used  :e
 :a prov:involved  :e
 :a a prov:Activity
 :e a prov:Entity
 :a prov:qualifiedUsage  :id
 :id a prov:Usage
 :id a prov:InstantaneousEvent
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e
 :id prov:atTime t^^xsd:dateTime
 :id  :attr_1 val_1
...
 :id  :attrn val_n



Issues:

Notes:

  • a "hadActivity" from the Involvement to the Activity is intentionally omitted. It's purpose is performed by its inverse "hadQualifiedUsage", which points from an Activity to an Involvement. This is done to maintain the design goal of "Entities and Activities are principle instances" and that the subjects of triples are more principal than objects of triples. -Tim

Agent Association

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
wasAssociatedWith(id,a,ag,pl,attrs)
==>  :a prov:wasAssociatedWith  :ag
 :a prov:involved  :ag
 :a a prov:Activity
 :ag a prov:Agent
 :ag a prov:Entity
 :a prov:qualifiedAssociation  :id
 :id a prov:Association
 :id a prov:AgentInvolvement
 :id a prov:Involvement
 :id prov:agent  :ag
 :id prov:hadPlan  :pl
 :id  :attr_1 val_1
...
 :id  :attr_n val_n
 :pl a prov:Plan
 :pl a prov:Entity 


prov:Plan rdfs:subClassOf prov:Entity .
# Furthermore, since plans may evolve over time, it may become 
# necessary to track their provenance, and hence, plans are entities. WD3


Issues:

Notes:

  • "hadActivity" is excluded; its purpose is fulfilled by prov:hadQualifiedAssociation (the preferred inverse)
  • the directionality of wasAssociatedWith follows the same as used: from Activity to Entity, following the goal of "pointing to what has existed longer"

Starting

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> [PROV-O] (eg)

PROV-N sd:name Subject Predicate Object
wasStartedBy(id,a,e,attrs)
==>  :a prov:wasStartedBy  :e
 :a a prov:Activity
 :e a prov:Entity
 :a prov:involved  :e
 :a prov:qualifiedStart  :id
 :id a prov:Start
 :id a prov:InstantaneousEvent
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e
 :id attr_1 val_1
...
 :id attr_n val_n

Ending

  • Mapped to OWL

PROV-DM <math>\implies</math> [PROV-O]

PROV-N sd:name Subject Predicate Object
wasEndedBy(id,a,e,attrs)
==>  :a prov:wasEndedBy  :e
 :a a prov:Activity
 :e a prov:Entity
 :a prov:involved  :e
 :a prov:qualifiedEnd  :id
 :id a prov:End
 :id a prov:InstantaneousEvent
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e
 :id attr_1 val_1
...
 :id attr_n val_n

Responsibility

TODO: review

  • Mapped to OWL

PROV-DM <math>\implies</math> PROV-O

PROV-N sd:name Subject Predicate Object
actedOnBehalfOf(id,ag2,ag1,a,attrs)
==>  :ag2 prov:actedOnBehalfOf  :ag1
 :ag2 a prov:Agent
 :ag2 a prov:Entity
 :ag1 a prov:Agent
 :ag1 a prov:Entity
 :ag2 prov:involved  :ag1
 :ag2 prov:qualifiedResponsibility  :id
 :id a prov:Responsibility
 :id a prov:AgentInvolvement
 :id a prov:Involvement
 :id prov:agent  :ag1
 :id prov:hadActivity  :a
 :id attr_1 val_1
...
 :id attr_n val_n
 :a a prov:Activity



Issues:

Derivation

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

https://www.w3.org/2011/prov/track/issues/294


PROV-N sd:name Subject Predicate Object
wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)
==>  :e2 prov:wasDerivedFrom  :e1
 :e2 a prov:Entity
 :e1 a prov:Entity
 :a a prov:Activity
 :g2 a prov:Generation
 :g2 a prov:InstantaneousEvent
 :g2 a prov:ActivityInvolvement
 :g2 a prov:Involvement
 :u1 a prov:Usage
 :u1 a prov:InstantaneousEvent
 :u1 a prov:EntityInvolvement
 :u1 a prov:Involvement
 :e2 prov:tracedTo  :e1
 :e2 prov:involved  :e1
 :e2 prov:involved  :a
 :e2 prov:qualifiedDerivation  :id
 :id a prov:Derivation
 :id a prov:InstantaneousEvent
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:wasDerivedBy  :a
 :id prov:hadGeneration  :g2
 :id prov:hadUsage  :u1
 :id  :attr_1 val_1
...
 :id  :attr_n val_n


Notes:

This RDF expansion is very verbose because of the infererred usage/generation links with the activity. The actual derivation is fully asserted using :e2 prov:qualifiedDerivation :id and :id with its direct properties.

TODO: Use different colour/font for inferred statements? For instance.. italics? Or can we keep such inference rules separately to avoid repeating them, including subclass hieararchy? I in many way prefer to show all superproperties and superclasses, because it would highlight cases where they might not make sense or is difficult. For instance above - is prov:Derivation always a prov:ActivityInvolvement? --Stian


Issue:

  • Show what non-activity specific wasDerivedFrom(id, e2, e1,
 [attr1=val1]) will look like as well? Introducing usage or generation
 will infer a single activity, but it's still possible to do derivation
 across multiple activities.



prov:wasDerivedFrom rdfs:subClassOf prov:tracedTo .


Revision

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> [PROV-O] (eg)

PROV-N sd:name Subject Predicate Object
wasRevisionOf(id,e2,e1,ag,attrs)
==>  :e2 prov:wasRevisionOf  :e1
 :e2 a prov:Entity
 :e1 a prov:Entity
 :e2 prov:wasDerivedFrom  :e1
 :e2 prov:tracedTo  :e1
 :e2 prov:involved  :e1
 :e2 prov:qualifiedRevision  :id
 :id a prov:Revision
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e1
 :id  :attr_1 val_1
...
 :id  :attr_n val_n 


prov:wasRevisionOf rdfs:subPropertyOf prov:wasDerivedFrom .

Attribution

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
wasAttributedTo(id,e,ag,attr)
==>  :e prov:wasAttributedTo  :ag
 :e a prov:Entity
 :ag a prov:Agent
 :ag a prov:Entity
 :e prov:tracedTo  :ag
 :e prov:involved  :ag
 :e prov:qualifiedAttribution  :id
 :id a prov:Attribution
 :id a prov:AgentInvolvement
 :id a prov:Involvement
 :id prov:agent  :ag
 :id attr_1 val_1
...
 :id attr_n val_n 


prov:wasAttributedTo rdfs:subPropertyOf prov:tracedTo .

Issues:

Quotation

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
wasQuotedFrom(id,e2,e1,ag2,ag1,attrs)
==>  :e2 prov:wasQuotedFrom  :e1
 :e2 a prov:Entity
 :e1 a prov:Entity
 :ag1 a prov:Agent
 :ag1 a prov:Entity
 :ag2 a prov:Agent
 :ag2 a prov:Entity
 :e2 prov:wasDerivedFrom  :e1
 :e2 prov:tracedTo  :e1
 :e2 prov:involved  :e1
 :e2 prov:qualifiedQuotation  :id
 :id a prov:Quotation
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e1
 :id prov:hadQuoter  :ag2
 :id prov:hadQuoted  :ag1
 :id attr_1 val_1
...
 :id attr_n val_n  :ag2


Issues:

Activity Ordering (informed by)

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
wasInformedBy(id,a2,a1,attrs)
==>  :a2 prov:wasInformedBy  :a1
 :a2 a prov:Activity
 :a1 a prov:Activity
 :a2 prov:involved  :a1
 :a2 prov:qualifiedInform  :id
 :id a prov:Inform
 :id a prov:ActivityInvolvement
 :id a prov:Involvement
 :id prov:activity  :a1
 :id attr_1 val_1
...
 :id attr_n val_n


Issues:

Started by activity

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
wasStartedByActivity(id, a2, a1, attrs)
==>  :a2 prov:wasStartedByActivity  :a1
 :a2 a prov:Activity
 :a1 a prov:Activity
 :a2 prov:involved  :a1
 :a2 prov:qualifiedStartByActivity  :id
 :id a prov:StartByActivity
 :id a prov:ActivityInvolvement
 :id a prov:Involvement
 :id prov:activity  :a1
 :id attr_1 val_1
...
 :id attr_n val_n

Traceability

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> [PROV-O] (eg)

PROV-N sd:name Subject Predicate Object
tracedTo(id,e2,e1,attrs)
==>  :e2 prov:tracedTo  :e1
 :e2 a prov:Entity
 :e1 a prov:Entity
 :e2 prov:involved  :e1
 :e2 prov:qualifiedTrace  :id
 :id a prov:Trace
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e1
 :id attr_1 val_1
...
 :id attr_n val_n

Original Source

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
hadOriginalSource(id,e2,e1,attrs)
==>  :e2 prov:hadOriginalSource  :e1
 :e2 a prov:Entity
 :e1 a prov:Entity
 :e2 prov:wasDerivedFrom  :e1
 :e2 prov:tracedTo  :e1
 :e2 prov:involved  :e1
 :e2 prov:qualifiedSource  :id
 :id a prov:Source
 :id a prov:EntityInvolvement
 :id a prov:Involvement
 :id prov:entity  :e1
 :id  :attr_1 val_1
...
 :id  :attr_n val_n

TODO: a Source? a Sourcing? SourceRelation? (e1 is the source, not id!)

AlternateOf

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

  • Mapped to OWL (without attributes)
PROV-N sd:name Subject Predicate Object
alternateOf(alt1,alt2)
==>  :alt1 prov:alternateOf  :e2
 :alt2 a prov:Entity
 :e2 a prov:Entity

NOTE: Attributes removed by vote on 1 march 2012.

SpecializationOf

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

  • Mapped to OWL (without attributes)
PROV-N sd:name Subject Predicate Object
specializationOf(sub,super)
==>  :sub prov:specializationOf  :super
 :sub a prov:Entity
 :super a prov:Entity

NOTE attributes removed by wg vote 1 march 2012.

Annotation

PROV-DM (eg) <math>\implies</math> [PROV-O] (eg)

  • Mapped to OWL
PROV-N sd:name Subject Predicate Object
hasAnnotation(r,n)
==>  :r prov:hasAnnotation  :n
 :n a prov:Note

NOTE: attributes removed by wg vote 1 mar 2012.


Issues:

Further terms in records

It's not clear to me that we need to spell these out as rules in the mapping. But, it is good to explain how attributes, literals, identifiers, times, etc. in PROV-DM map to PROV-O-compliant RDF. ---[James]

Attribute

  • Mapped to OWL (except prov:steps)

http://www.w3.org/TR/2012/WD-prov-dm-20120202/#record-attribute PROV-DM] (eg) <math>\implies</math> PROV-O (eg)

Note that the following patterns are implicit in the above rules for the various constructs that carry ids and attributes ---[James]


PROV-N sd:name Subject Predicate Object
...(id, ..., prov:role = myrole)
==>  :id prov:hadRole  :myrole
 :myrole a prov:Role


<math> \begin{array}{lcl} ...(id, ..., \texttt{prov:type}=\texttt{prov:SoftwareAgent}) &\to& \left\{ \begin{array}{lcl} 

 id & \texttt{a} & \texttt{prov:SoftwareAgent}\ .\\
 id & \texttt{a} & \texttt{prov:Agent}\ .\\
 id & \texttt{a} & \texttt{prov:Entity}\ .\\

\end{array}\right. \end{array} </math>


PROV-N sd:name Subject Predicate Object
...(id, ..., prov:label = "pretty")
==>  :myrole rdfs:label "pretty"

Identifier

As per PROV-DM, an identifier is a qualified name in the same sense as in RDF/SPARQL.

Literal

PROV-DM literals include values that can be typed by XML Schema basic types, and thus can include URIs (unlike RDF's Literals). Thus, some care may need to be taken here when mapping PROV-DM literals that are URIs.

Time

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

Namespace declaration

A PROV-DM namespace declaration should be translated to an XML namespace declaration (for RDF/XML); or other RDF serializations the appropriate mechanism should be used.

Location

  • Mapped to OWL

PROV-DM (eg) <math>\implies</math> PROV-O (eg)

PROV-N sd:name Subject Predicate Object
...(id, [..., location=loc])
==>  :id prov:hadLocation  :loc
 :loc a prov:Location

Issues:

Common Relations

Collections

PROV-DM (eg) <math>\implies</math> PROV-O


Collection insertion

PROV-N sd:name Subject Predicate Object
derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)}, attrs)
 :c2 prov:derivedByInsertionFrom  :c1
==>  :c2 a prov:Collection
 :c2 a prov:Entity
 :c1 a prov:Collection
 :c1 a prov:Entity
 :c2 prov:wasDerivedFrom  :c1
 :c2 prov:tracedTo  :c1
 :c2 prov:involved  :c1
 :c2 prov:qualifiedInsertion  :id
 :id a prov:Insertion
 :id a prov:CollectionInvolvement
 :id a prov:Involvement
 :id prov:collection  :c1
 :id prov:inserted  :kv_1
 :kv_1 a prov:KeyValuePair
 :kv_1 prov:key "key_1"^^xsd:string
 :kv_1 prov:value  :e_1
...
 :id prov:inserted  :kv_n
 :kv_n a prov:KeyValuePair
 :kv_n prov:key "key_n"^^xsd:string
 :kv_n prov:value  :e_n
 :id  :attr_1 val_1
...
 :id  :attr_n val_n

Collection removal

PROV-N sd:name Subject Predicate Object
derivedByRemovalFrom(id, c2, c1, {key_1, ... key_n}, attrs)
 :c2 prov:derivedByRemovalFrom  :c1
==>  :c2 a prov:Collection
 :c2 a prov:Entity
 :c1 a prov:Collection
 :c1 a prov:Entity
 :c2 prov:wasDerivedFrom  :c1
 :c2 prov:tracedTo  :c1
 :c2 prov:involved  :c1
 :c2 prov:qualifiedRemoval  :id
 :id a prov:Removal
 :id a prov:CollectionInvolvement
 :id a prov:Involvement
 :id prov:collection  :c1
 :id prov:removedKey "key_1"^^xsd:string
...
 :id prov:removedKey "key_n"^^xsd:string
 :id  :attr_1 val_1
...
 :id  :attr_n val_n


Collection membership

PROV-N sd:name Subject Predicate Object
memberOf(id, c, {(key_1, e_1), ..., (key_n, e_n)}, complete, attrs)
 :c2 prov:membership  :id
==>  :c2 a prov:Collection
 :c2 a prov:Entity
If complete==true  :id a prov:CompleteMembership
 :id a prov:Membership
 :id prov:member  :kv_1
 :kv_1 a prov:KeyValuePair
 :kv_1 prov:key "key_1"^^xsd:string
 :kv_1 prov:value  :e_1
...
 :id prov:member  :kv_n
 :kv_n a prov:KeyValuePair
 :kv_n prov:key "key_n"^^xsd:string
 :kv_n prov:value  :e_n
 :id  :attr_1 val_1
...
 :id  :attr_n val_n

Characteristics of Object Properties

The table below summarizes the characteristics of the object properties that are defined in the OWL ontology. The question mark symbol is used to denote that the characteristic in question is under discussion by the WG (this is the case for alternateOf where an issue was raised to determine if it is transitive), or because I am not sure whether the property in question is supported bye the object property. I am also using (Yes) and (No) to denote properties that I am not sure of, but for which I am inclined to say yes or no. These also need to be discussed with the rest of the prov-o team. -- khalid

Functional Reverse functional Transitive Symmetric Asymmetric Reflexive Irreflexive
prov:activity Yes No No No Yes No Yes
prov:hadPlan ? No No No Yes No Yes
prov:alternateOf No No ? Yes No Yes No
prov:endedAtTime Yes No No No Yes No Yes
prov:entity Yes No No No Yes No Yes
prov:hadQuotedAgent Yes No No No Yes No Yes
prov:hadQuoterAgent Yes No No No Yes No Yes
prov:wasGeneratedBy Yes No No No Yes No Yes
prov:hadRole (Yes) No No No Yes No Yes
prov:hadLocation (Yes) No No No Yes (Yes) (No)
prov:hasAnnotation No (No) No No Yes No Yes
prov:involved ? ? ? ? ? ? ?
prov:actedOnBehalfOf (No) No No No No No Yes
prov:generated No Yes No No Yes No Yes
prov:tracedTo No No Yes No Yes No Yes
prov:wasAttributedTo Yes No (No) No Yes No Yes
prov:wasDerivedFrom No No No No Yes No Yes
prov:hadOriginalSource Yes No (No) No Yes No Yes
prov:wasQuotedFrom (Yes) No (No) No Yes No Yes
prov:wasRevisionOf No No Yes No Yes No Yes
prov:used No No No No Yes No Yes
prov:wasAssociatedWith No No No No Yes No Yes
prov:wasEndedBy ? No No No Yes No Yes
prov:wasStartedBy ? No No No Yes No Yes
prov:wasGeneratedBy Yes No No No Yes No Yes
prov:wasInformedBy No No (No) No No No No
prov:wasStartedByActivity ? ? ? ? ? ? ?
prov:atTime Yes No No No Yes No Yes
prov:specializationOf No No Yes No Yes (Yes) (No)
prov:startedAtTime Yes No No No Yes No Yes

WG feedback Feb 2012

http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.02.23#PROV-O_Ontology:_Reviewer_feedback

Questions/problems

  • The activity record is the only one that mentions additional things besides attributes. This seems odd.
    • Proposal: wasStartedBy, wasEndedBy and activity records / times are all under review in PROV-DM, so hopefully this will be addressed.
  • It isn't obvious whether we should emit a triple saying that the plan element of an activity is a <math>\texttt{prov:Plan}</math>. I guess this can be inferred if we omit it?
    • [Resolved: we give it explicitly]
  • In the rule for note, there is no class we can assign to the id. (The obvious idea of using rdfs:comment doesn't work because there's no separate class for the comments, and the range of rdfs:comment is Literal.) Is this a problem?
    • Proposed solution: add class prov:Note.
    • Resolved: PROV-O now has class Note
  • wasGeneratedBy has a time which can be linked to the generated entity by <math>\texttt{prov:wasGeneratedAt}</math>, but I think the time should be linked directly to the id.
    • Proposed solution: introduce <math>\texttt{prov:happenedAt}</math>, define <math>\texttt{prov:wasGeneratedAt}</math> as the composition of <math>\texttt{prov:happenedAt}</math> and <math>\texttt{prov:hadQualifiedEntity}</math>.
    • Resolved: handling using atTime for now
  • used has a time and it's not obvious what this should be linked to in RDF and how. There is no relation for linking the used id to the time.
    • Proposed solution: introduce <math>\texttt{prov:happenedAt}</math>.
    • Resolved: using atTime for now
  • wasStartedBy and wasEndedBy are treated as events (and they have id's and attributes), but there is no class for them.
    • Proposed solution: introduce <math>\texttt{prov:ActivityStart}</math> and <math>\texttt{prov:ActivityEnd}</math> as subclasses of QualifiedInvolvement.
    • Resolved: using prov:Start and prov:End
  • In hasAnnotation, should the attributes be connected to r or to n? Given that the note n can have arbitrary attributes, why does hasAnnotation have additional attributes?
    • Proposal: Suggest that DM consider dropping attributes on hasAnnotation and instead recommends subclassing Note to express different kinds of notes.

From PROV-O to PROV-DM

Given an instance of PROV-O, we want to compute an instance of PROV-DM that has the "same meaning".

The basic idea is:

  1. For each node in the RDF graph, check whether the node is an instance of one of the PROV-O classes Entity, Agent, or Activity.
    1. For each such node, look for the appropriate edges in the prov: namespace needed to fill in the fields of the corresponding PROV-DM record.
    2. Any additional fields in other namespaces are added as attributes.
  2. For each of the edges / graph patterns corresponding to PRO-DM relations, look for the corresponding data and generate the appropriate relation.

[TODO: Flesh this out!]

Retrieved from "https://www.w3.org/2011/prov/wiki/index.php?title=ProvRDF&oldid=11302"