OWL 2 extends the W3C OWL Web Ontology Language
with a small but useful set of features that have been requested by
users, for which effective reasoning algorithms are now available,
and that OWL tool developers are willing to support. The new
features include extra syntactic sugar, additional property and
qualified cardinality constructors, extended datatype support,
simple metamodeling, and extended annotations.
This document defines a mapping of OWL 2 ontology into the RDF
syntax, and vice versa.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Set of Documents
This document is being published as one of a set of 11 documents:
The Working Group believes it has completed its design work for the technologies specified this document, so this is a "Last Call" draft. The design is not expected to change significantly, going forward, and now is the key time for external review, before the implementation phase.
Summary of Changes
This document has been updated to keep in sync with the Syntax document. Apart from that, the biggest change is in the new treatment of owl:imports, which is summarized in Section 3.1.
Please Comment By 23 January 2009
The OWL Working Group seeks
public feedback on these Working Drafts. Please send your
comments to public-owl-comments@w3.org (public archive). If possible, please offer
specific changes to the text that would address your
concern. You may also wish to check the Wiki
Version of this document for internal-review comments and changes being
drafted which may address your concerns.
No Endorsement
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document defines mappings by means of which every OWL 2
ontology [OWL 2
Specification] can be mapped into an RDF graph and back.
These transformations do not incur any change in the formal meaning
of the ontology. More precisely, let O be any OWL 2
ontology, let T(O) be the RDF graph obtained by transforming
O as specified in Section 2, and let O' be the OWL 2 ontology obtained
by applying the reverse transformation from Section 3 to T(O); then, O and O' are
logically equivalent — that is, they have exactly the same set of
models.
The mappings presented in this document are backwards-compatible
with that of OWL DL: every OWL DL ontology encoded as an RDF graph
can be mapped into a valid OWL 2 ontology using the
reverse-transformation from Section 3 such that the resulting OWL 2 ontology has exactly
the same set of models as the original OWL DL ontology.
The syntax for triples used in this document is the one used in
the RDF Semantics [RDF
Semantics]. Full IRIs are abbreviated using the
namespaces from the OWL 2 Specification [OWL 2
Specification]. OWL 2 ontologies mentioned in this
document should be understood as instances of the structural
specification of OWL 2 [OWL 2 Specification]; when required, these are
written in this document using the functional-style syntax.
The following notation is used throughout this document for
referring to parts of RDF graphs:
*:x denotes an IRI reference;
_:x denotes a blank node;
x denotes a blank node or an IRI
reference; and
lt denotes a literal.
The italicized keywords MUST, MUST NOT, SHOULD,
SHOULD
NOT, and MAY specify certain aspects of the normative
behavior of OWL 2 tools, and are interpreted as specified in RFC
2119 [RFC
2119].
2 Mapping from the Structural
Specification to RDF Graphs
This section defines a mapping of an OWL 2 ontology O
into an RDF graph T(O). The mapping is presented in three
parts. Section 2.1 shows how to translate axioms that do not
contain annotations, Section 2.2 shows how to translate annotations, and Section 2.3
shows how to translate axioms containing annotations.
2.1 Translation of Axioms without
Annotations
Table 1 presents the operator T that maps an OWL 2
ontology O into an RDF graph T(O), provided that no
axiom in O is annotated. The mapping is defined recursively;
that is, the mapping of a construct often depends on the mappings
of its subconstructs, but in a slightly unusual way: if the mapping
of a construct refers to the mapping of a subconstruct, then the
triples generated by the recursive invocation of T are added
to the graph under construction, and its main node is used
in place of the invocation itself.
The definition of the operator T uses the operator
TANN in order to translate annotations. The operator
TANN is defined in Section 2.2. It takes an annotation and an IRI
reference or a blank node and produces the triples that attach the
annotation to the supplied object.
In the mapping, each generated blank node (i.e., each blank node
that does not correspond to an anonymous individual) is fresh in
each application of a mapping rule. Furthermore, the following
conventions are used in this section to denote different parts of
OWL 2 ontologies:
OP denotes an object property;
OPE denotes an object property
expression;
DP denotes a data property;
DPE denotes a data property
expression;
PE denotes an object or a data
property expression;
AP denotes an annotation
property;
C denotes a class;
CE denotes a class expression;
DT denotes a datatype;
DR denotes a data range;
U denotes an IRI;
F denotes a constraining facet;
a denotes an individual (named or
anonymous);
*:a denotes a named individual;
lt denotes a literal;
as denotes an annotation source;
and
av denotes an annotation value.
In this section, T(SEQ y1 ...
yn) denotes the translation of a sequence of
objects from the structural specification into an RDF list, as
shown in Table 1.
If an axiom ax contains embedded annotations annotation1 ... annotationm,
its serialization into RDF depends on the type of the axiom. Let
ax' be the axiom that is obtained from ax by removing
all axiom annotations.
2.3.1 Axioms that Generate a Single
Triple or that Have a Main Triple
If ax' is translated into a single RDF triple
s p o, then the axiom ax is
translated into the following triples:
s p o
_:x rdf:typeowl:Axiom
_:x owl:subject s
_:x owl:predicate p
_:x owl:object o
TANN(annotation1, _:x)
...
TANN(annotationm, _:x)
This is the case for the following axioms: SubClassOf, DisjointClasses with two classes, SubPropertyOf without a property chain as the
subproperty expression, PropertyDomain, PropertyRange, InverseProperties, FunctionalProperty, InverseFunctionalProperty, ReflexiveProperty, IrreflexiveProperty, SymmetricProperty, AsymmetricProperty, TransitiveProperty, DisjointProperties with two properties,
ClassAssertion, PropertyAssertion, Declaration, DifferentIndividuals with two individuals, and
AnnotationAssertion.
Consider the following subclass axiom:
SubClassOf( Annotation( rdfs:comment "Children are
people." ) a:Childa:Person )
Without the annotation, the axiom would be translated into the
following triple:
a:Childrdfs:subClassOfa:Person
Thus, the annotated axiom is transformed into the following
triples:
DisjointUnion, SubPropertyOf with a subproperty chain, and
HasKey axioms are, without
annotations, translated into several, and not a single triple. If
such such axioms are annotated, then the main triple is
subjected to the transformation described above. The other triples
— called side triples — are output without any change.
Consider the following subproperty axiom:
SubPropertyOf( Annotation( rdfs:comment "An aunt is a
mother's sister." ) PropertyChain( a:hasMothera:hasSister ) a:hasAunt ) )
Without the annotation, the axiom would be translated into the
following triples:
In order to capture the annotation on the axiom, the first
triple plays the role of the main triple for the axiom, so it is
represented using a fresh blank node _:x
in order to be able to attach the annotation to it. The original
triple is output alongside all other triples as well.
_:x rdf:typeowl:Axiom
_:x owl:subject _:y
_:x owl:predicaterdfs:subPropertyOf
_:x owl:objecta:hasAunt
_:x rdfs:comment "An aunt is a mother's
sister."^^xsd:string
In order to capture the annotation on the axiom, the first
triple plays the role of the main triple for the axiom, so it is
represented using a fresh blank node _:x
in order to be able to attach the annotation to it.
2.3.2 Axioms that are Translated to
Multiple Triples
If the axiom ax' is of type EquivalentClasses, EquivalentProperties, or SameIndividual, its translation into RDF can
be broken up into several RDF triples (because RDF can only
represent binary relations). In this case, each of the RDF triples
obtained by the translation of ax' is transformed as
described in previous section, and the annotations are repeated for
each of the triples obtained in the translation.
This axiom is first split into the following equalities between
pairs of individuals, and the annotation is repeated on each axiom
obtained in this process:
If the axiom ax' is of type NegativePropertyAssertion, DisjointClasses with more than two classes,
DisjointObjectProperties or
DisjointDataProperties with more
than two properties, or DifferentIndividuals with more than two
individuals, then its translation already requires introducing a
blank node _:x. In such cases, ax is translated by first
translating ax' into _:x as shown in Table 1, and then
attaching the annotations of ax to _:x.
Consider the following negative property assertion:
Even without the annotation, this axiom would be represented
using a blank node. The annotation can readily be attached to this
node, so the axiom is transformed into the following triples:
3 Mapping from RDF Graphs to the
Structural Specification
This section specifies the results of steps CP-2.2 and CP-3.3 of
the canonical parsing process from Section 3.6 of the OWL 2
Specification [OWL 2 Specification] on an ontology document D
that can be parsed into an RDF graph G. An OWL 2 tool
MAY
implement these steps in any way it chooses; however, the results
MUST be
structurally equivalent to the ones defined in the following
sections. These steps do not depend on the RDF syntax used to
encode the RDF graph in D; therefore, the ontology document
D is identified in this section with the corresponding RDF
graph G.
An RDF syntax ontology document is any sequence of octets
accessible from some given IRI that can be parsed into an RDF
graph, and that then be transformed into an OWL 2 ontology by the
canonical parsing process instantiated as specified in this
section.
The following sections contain rules in which triple patterns
are matched to G. If a triple pattern contains a variable
number of triples, the maximal possible subset of GMUST be
matched. The following notation is used in the patterns:
The notation NN_INT(n) can be matched
to any literal whose value n is a
nonnegative integer.
Possible conditions on the pattern are enclosed in curly braces
{ }.
Some patterns use optional parts, which are enclosed in square
brackets '[ ]'.
The abbreviation T(SEQ y1 ...
yn) denotes the pattern corresponding to RDF
lists, as shown in Table 3.
Table 3. Patterns
Corresponding to RDF Lists
Sequence S
Triples Corresponding to T(S)
Main Node of T(S)
SEQ
rdf:nil
SEQ y1 ... yn
_:x rdf:first y1
_:x rdf:rest T(SEQ y2 ...
yn)
_:x
3.1 Extracting Declarations and the
IRIs of the Directly Imported Ontology Documents
This section specifies the result of step CP-2.2 of the
canonical parsing process on an RDF graph G
3.1.1 Resolving Included RDF
Graphs
For backwards compatibility with OWL DL, if G contains an
owl:imports triple pointing to an RDF graph G' and
G' does not have an ontology header, this owl:imports
triple is interpreted as an include rather than an import —
that is, the triples of G' are included into G and
are not parsed into a separate ontology. To achieve this, the
following transformation is applied to G as long as the
following rule is applicable to G.
If G contains a pair of triples of the form
x rdf:typeowl:Ontology
x owl:imports *:y
and the values for x and *:y have not already been considered, the following
actions are performed:
The ontology document accessible from the IRI *:y is retrieved as specified in Section 3.2 of the
OWL 2 Specification [OWL 2 Specification].
The document is parsed into an RDF graph G' using an
appropriate RDF syntax.
If the parsing succeeds and the graph G' does not
contain a triple of the form
z rdf:typeowl:Ontology
then G' is merged (as in RDF Semantics [RDF Semantics]) into
G and the triple
x owl:imports *:y
is removed from G.
3.1.2 Parsing of the Ontology Header
and Declarations
Next, the ontology header is extracted from G by matching
patterns from Table 4 to G. It MUST be possible to
match exactly one such pattern to G in exactly one way. The
matched triples are removed from G. The set Imp(G) of
the IRIs of ontology documents that are directly imported into
G contains exactly all *:z1,
..., *:zk that are matched in the pattern.
Table 4. Parsing of the
Ontology Header
If G contains this pattern...
...then the ontology header has this form.
*:x rdf:typeowl:Ontology
[ *:x owl:versionInfo *:y ]
*:x owl:imports *:z1
...
*:x owl:imports *:zk
{ The following triple pattern cannot be matched in G:
u w *:x
u rdf:typeowl:Ontology
w rdf:typeowl:OntologyProperty
}
_:x rdf:typeowl:Ontology
_:x owl:imports *:z1
...
_:x owl:imports *:zk
{ The following triple pattern cannot be matched in G:
u w _:x
u rdf:typeowl:Ontology
w rdf:typeowl:OntologyProperty
}
Ontology(
Import( *:z1 )
...
Import( *:zk )
...
)
Next, for backwards compatibility with OWL DL, certain redundant
triples are removed from G. In particular, if the triple
pattern from the left-hand side of Table 5 is matched in G,
then the triples on the right-hand side of Table 5 are removed from
G.
Table 5. Triples to be
Removed for Backwards Compatibility with OWL DL
If G contains this pattern...
...then these triples are removed from G.
x rdf:typeowl:Ontology
x rdf:typeowl:Ontology
x rdf:typeowl:Class
x rdf:typerdfs:Class
x rdf:typerdfs:Class
x rdf:typerdfs:Datatype
x rdf:typerdfs:Class
x rdf:typerdfs:Class
x rdf:typeowl:DataRange
x rdf:typerdfs:Class
x rdf:typerdfs:Class
x rdf:typeowl:Restriction
x rdf:typerdfs:Class
x rdf:typerdfs:Class
x rdf:typeowl:Restriction
x rdf:typeowl:Class
x rdf:typeowl:Class
x rdf:typeowl:ObjectProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typeowl:FunctionalProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typeowl:InverseFunctionalProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typeowl:TransitiveProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typeowl:DatatypeProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typeowl:AnnotationProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typeowl:OntologyProperty
x rdf:typerdf:Property
x rdf:typerdf:Property
x rdf:typerdf:List
x rdf:first y
x rdf:rest z
x rdf:typerdf:List
Next, for backwards compatibility with OWL DL, G is
modified such that declarations can be properly extracted in the
next step. When a triple pattern from the first column of Table 6
is matched in G, the matching triples are replaced in
G with the triples from the second column. This matching phase
stops when matching a pattern and replacing it as specified does
not change G. Note that G is a set and thus cannot
contain duplicate triples, so this last condition prevents infinite
matches.
Table 6. Additional
Declaration Triples
If G contains this pattern...
...then the matched triples are replaced in G with these
triples.
Next, the set of declarations Decl(G) is extracted from
G according to Table 7. The matched triples are not removed
from G — the triples from Table 7 can contain annotations
so, in order to correctly parse the annotations, they will be
matched again in the step described in Section 3.2.5.
Finally, the set RIND of anonymous
individuals used in reification is identified. This is done by
initially setting RIND = ∅ and then
applying the patterns shown in Table 8. The matched triples are not
deleted from G.
Table 8. Identifying
Anonymous Individuals in Reification
If G contains this pattern, then :_x is added to RIND.
_:x rdf:typeowl:Axiom
_:x rdf:typeowl:Annotation
_:x rdf:typeowl:AllDisjointClasses
_:x rdf:typeowl:AllDisjointProperties
_:x rdf:typeowl:AllDifferent
_:x rdf:typeowl:NegativePropertyAssertion
3.2 Populating an
Ontology
This section specifies the result of step CP-3.3 of the
canonical parsing process on an RDF graph G, the
corresponding instance OG of the Ontology class, and the set AllDecl(G)
of all declarations for G computed as specified in step
CP-3.1 of the canonical parsing process.
3.2.1 Analyzing
Declarations
The following functions map an IRI reference or a blank node
x occurring in G into an object of
the structural specification. In particular,
CE(x) maps x into a class expression,
DR(x) maps x into a data range,
OPE(x) maps x into an object property expression,
DPE(x) maps x into a data property expression, and
AP(x) maps x into an annotation property.
Initially, these functions are undefined for all IRIs and blank
nodes occurring in G; this is written as CE(x) = ε, DR(x) = ε,
OPE(x) = ε, DPE(x) =
ε, and AP(x) = ε. The functions
are updated as parsing progresses. All of the following conditions
MUST be
satisfied at any given point in time during parsing.
For each x, at most one of
OPE(x), DPE(x),
and AP(x) is defined.
For each x, at most one of
CE(x) and DR(x)
is defined.
Furthermore, the value of any of these functions for any
xMUST NOT be
redefined during parsing (i.e., if a function is not undefined for
x, no attempt should be made to change
the function's value for x).
The function OPEorDPE is defined as
follows:
OPEorDPE(x) = OPE(x) if OPE(x) ≠ ε;
OPEorDPE(x) = DPE(x) if DPE(x) ≠ ε;
and
OPEorDPE(x) = ε otherwise.
Functions CE, DR, OPE, DPE, and AP are initialized
as shown in Table 9.
Table 9. Initialization of
CE, DR,
OPE, DPE, and
AP
If AllDecl(G) contains this declaration...
...then perform this assignment.
Declaration( Class( *:x ) )
CE(*:x) := a class with the IRI *:x
Declaration( Datatype( *:x ) )
DR(*:x) := a datatype with the IRI *:x
Declaration( ObjectProperty( *:x ) )
OPE(*:x) := an object property with the IRI
*:x
Declaration( DataProperty( *:x ) )
DPE(*:x) := a data property with the IRI *:x
Declaration( AnnotationProperty( *:x ) )
AP(*:x) := an annotation property with the IRI
*:x
3.2.2 Parsing of
Annotations
The annotations in G are parsed next. The function
ANN assigns a set of annotations
ANN(x) to each IRI reference or a blank
node x. This function is initialized by
setting ANN(x) = ∅ for each each IRI
reference or a blank node x. Next, the
triple patterns from Table 10 are matched in G and, for each
matched pattern, ANN(x) is extended with
an annotation from the right column. Each time one of these triple
patterns is matched, the matched triples are removed from G.
This process is repeated until no further matches are possible.
Table 10. Parsing of
Annotations
If G contains this pattern...
...then this annotation is added to ANN(x).
x *:y z
{ AP(*:y) ≠ ε,
z is an IRI reference or a blank node, and
there is no blank node _:w such that G contains the
triples
_:w rdf:typeowl:Annotation
_:w owl:subject x
_:w owl:predicate *:y
_:w owl:object z }
Annotation( *:y z )
x *:y z
_:w rdf:typeowl:Annotation
_:w owl:subject x
_:w owl:predicate *:y
_:w owl:object z
{ AP(*:y) ≠ ε,
z is an IRI reference or a blank node, and
no other triple in G contains _:w in subject or
object position }
Annotation( ANN(_:w) *:y z )
3.2.3 Parsing of Ontology
Annotations
Let x be the node that was matched in
G to *:x or _:x according to the patterns from Table 4; then,
ANN(x) determines the set of ontology
annotations of OG.
3.2.4 Parsing of
Expressions
Next, functions OPE, DR, and CE are extended as
shown in Tables 11, 12, and 13, as well as in Tables 14 and 15. The
patterns in the latter two tables are not generated by the mapping
from Section 2, but they can be present in RDF graphs that encode
OWL DL ontologies. Each time a pattern is matched, the matched
triples are removed from G. Pattern matching is repeated
until no triple pattern can be matched to G.
Table 11. Parsing Object
Property Expressions
If G contains this pattern...
...then OPE(_:x) is set to this object property
expression.
Next, OG is populated with axioms. For
clarity, the axiom patterns are split into two tables.
Table 16 presents the patterns for axioms without
annotations.
Annotated axioms are parsed as follows:
In case of the patterns for owl:AllDisjointClasses,
owl:AllDisjointProperties, owl:AllDifferent, and
owl:NegativePropertyAssertion, axiom annotations are defined
by ANN(_:x).
For all other axioms, axiom annotations are obtained by
additionally matching patterns from Table 17 in G during
axiom matching.
The axioms in G are parsed as follows:
All annotated axioms are parsed first.
Only when no pattern for annotated axioms can be matched in
G, then the patterns for axioms without annotations are
matched.
In either case, each time a triple pattern is matched, the
matched triples are removed from G.
Table 16. Parsing of Axioms
without Annotations
If G contains this pattern...
...then the following axiom is added to
OG.
*:x rdf:typeowl:Class
Declaration( Class( *:x ) )
*:x rdf:typerdfs:Datatype
Declaration( Datatype( *:x ) )
*:x rdf:typeowl:ObjectProperty
Declaration( ObjectProperty( *:x ) )
*:x rdf:typeowl:DatatypeProperty
Declaration( DataProperty( *:x ) )
*:x rdf:typeowl:AnnotationProperty
Declaration( AnnotationProperty( *:x ) )
*:x rdf:typeowl:NamedIndividual
Declaration( NamedIndividual( *:x ) )
x rdfs:subClassOf y
{ CE(x) ≠ ε and CE(y) ≠ ε }
SubClassOf( CE(x) CE(y) )
x owl:equivalentClass y
{ CE(x) ≠ ε and CE(y) ≠ ε }
EquivalentClasses( CE(x) CE(y) )
x owl:disjointWith y
{ CE(x) ≠ ε and CE(y) ≠ ε }
DisjointClasses( CE(x) CE(y) )
_:x rdf:typeowl:AllDisjointClasses
_:x owl:members T(SEQ y1 ... yn)
{ n ≥ 2 and CE(yi) ≠ ε for each 1 ≤ i ≤ n }
DisjointClasses( CE(y1) ... CE(yn) )
x owl:disjointUnionOf T(SEQ y1 ...
yn)
{ n ≥ 2,
CE(x) ≠ ε, and
CE(yi) ≠ ε for each 1 ≤ i ≤ n }
DisjointUnion( CE(x) CE(y1) ... CE(yn)
)
x rdfs:subPropertyOf y
{ OPE(x) ≠ ε and OPE(y) ≠ ε }
SubPropertyOf( OPE(x) OPE(y) )
_:x rdfs:subPropertyOf y
_:x owl:propertyChain T(SEQ x1 ...
xn)
{ n ≥ 2,
OPE(xi) ≠ ε for each 1 ≤ i ≤ n, and
OPE(y) ≠ ε }
s *:p o
_:x rdf:typeowl:Axiom
_:x owl:subject s
_:x owl:predicate *:p
_:x owl:object o
{ s *:p o is the main triple for an axiom according to Table 17
and G contains possible necessary side triples for the
axiom }
The result is the axiom corresponding to s *:p o
(and possible side triples) that additionally
contains the annotations ANN(_:x).
Next, for each blank node or IRI reference x such that x ∉
RIND, and for each annotation
Annotation( annotation1 ...
annotationn AP y ) ∈ ANN(x) with n possibly
being equal to zero, the following annotation assertion is added to
OG:
AnnotationAssertion( annotation1 ...
annotationn AP x y )
Finally, the patterns from Table 18 are matched in G, the
resulting axioms are added to OG. These patterns
are not generated by the mapping from Section 2, but they can be present in RDF graphs that encode
OWL DL ontologies. (Note that the patterns from the table do not
contain triples of the form *:x rdf:typeowl:Class because such triples are removed while
parsing the entity declarations, as specified in Section
3.1.2.) Each time a triple pattern is matched, the matched
triples are removed from G.
Table 18. Parsing of Axioms
for Compatibility with OWL DL
If G contains this pattern...
...then the following axiom is added to
OG.
*:x owl:complementOf y
{ CE(*:x) ≠ ε and CE(y) ≠ ε }
This document is the product of the OWL Working Group (see
below) whose members deserve recognition for their time and
commitment. The editors extend special thanks to Alan Ruttenberg
(Science Commons), Uli Sattler (University of Manchester) and Evren
Sirin (Clark & Parsia), for their thorough reviews.
The regular attendees at meetings of the OWL Working Group at
the time of publication of this document were: Jie Bao (RPI), Diego
Calvanese (Free University of Bozen-Bolzano), Bernardo Cuenca Grau
(Oxford University), Martin Dzbor (Open University), Achille Fokoue
(IBM Corporation), Christine Golbreich (Université de Versailles
St-Quentin), Sandro Hawke (W3C/MIT), Ivan Herman (W3C/ERCIM), Rinke
Hoekstra (University of Amsterdam), Ian Horrocks (Oxford
University), Elisa Kendall (Sandpiper Software), Markus Krötzsch
(FZI), Carsten Lutz (Universität Bremen), Boris Motik (Oxford
University), Jeff Pan (University of Aberdeen), Bijan Parsia
(University of Manchester), Peter F. Patel-Schneider (Bell Labs
Research, Alcatel-Lucent), Alan Ruttenberg (Science Commons), Uli
Sattler (University of Manchester), Michael Schneider (FZI), Mike
Smith (Clark & Parsia), Evan Wallace (NIST), and Zhe Wu (Oracle
Corporation). We would also like to thank past members of the
working group: Jeremy Carroll, Jim Hendler and Vipul Kashyap.