RDF Containers In N3, we could say that Ed (with id 21) and Bill (with id 34) created a certain document exstaff:. [ a foaf:Document; dc:creator exstaff:21, exstaff:34 ]. But might want to emphasize that they worked as a group  It was actually this group that created the document

RDF provides a container vocabulary consisting of  3 predefined types and  some predefined properties A container is a resource that contains things  The contained things are members  They’re resources (including blank nodes) or literals Three types of containers: rdf:Bag rdf:Seq rdf:Alt A Bag (resource having type rdf:Bag ) is a group of resources or literals  May have duplicate members  No significance to the order of the members

A Sequence or Seq ( resource having type rdf:Seq ) is a group of resources or literals  May have duplicate members  Order of the members is significant An Alternative or Alt (a resource having type rdf:Alt ) is a group of resources or literals that are alternatives  Typically alternatives for a single value of a property  An application using a property whose value is an Alt should be aware that it can choose any 1 of the members

To show that a resource is of a container type, give it an rdf:type property whose value is one of the predefined resources rdf:Bag, rdf:Seq, or rdf:Alt  The container resource (usually a blank node but possibly a resource with a URIref) denotes the group as a whole A member is described by defining a container membership property  The container resource is its subject  The member is its object These membership properties have names of the form rdf:_n, where n is a decimal integer > 0, with no leading 0’s  E.g., rdf:_1, rdf:_2, rdf:_3, … Container resources may have other properties besides the container membership properties and the rdf:type property

Express in N3 that Ed and Bill (as a group) created a certain document  Recall that, in N3, can abbreviate rdf:type as exstaff:. [ a foaf:Document; dc:creator [ a rdf:Bag; rdf:_1 exstaff:21; rdf:_2 exstaff:34 ] ]. No suggestion that 21 is the first author Keep in mind that RDF has no built-in understanding of what a resource of type rdf:Bag is  Applications must be written to behave according to the meaning

Expressed in N-Triples _:bnode0. _:bnode1. _:bnode1. _:bnode1. _:bnode0 _:bnode1. The graph Since no URIref is specified, the Bag is a bnode

The corresponding RDF/XML  Use the abbreviation for typed nodes to replace rdf:Description and an rdf:type element with a single rdf:Bag element <rdf:RDF xmlns:rdf=" xmlns:foaf=" xmlns:exstaff=" xmlns:dc="

rdf:li (inspired by HTML “list item”, “ li ”) is a convenience element  Avoid explicitly numbering each membership property  Numbered properties rdf:_1, rdf:_2, … are generated from the rdf:li elements to form the graph Rewrite the above N3 exstaff:. [ a foaf:Document; dc:creator [ a rdf:Bag; rdf:li exstaff:21, exstaff:34 ] ].

Similar change introducing rdf:li in the RDF/XML document  Two of the triples the Validator produces are genid:A genid:A  Note that “ _1 ” and “ _2 ” are substituted for “ li ”

To illustrate an Alt container, consider the sentence The source code for X11 may be found at ftp.example.org, ftp1.example.org, or ftp2.example.org In RDF/XML <rdf:RDF xmlns:rdf=" xmlns:s="

The graph is The corresponding s:. s:DistributionSite [ a rdf:Alt; rdf:li,, ].

An Alt container is intended to have at least 1 member, identified by property rdf:_1  Considered the default or preferred value  The order of the remaining elements isn’t significant Alt containers are often used in conjunction with language tagging  Alternative versions of a work in different languages  RDF/XML permits the use of the XML xml:lang attribute Indicates that the element content is in a specified language

As written, the above states simply that the value of the s:DistributionSite site property is the Alt container resource itself Any additional meaning must be built into  an application's understanding of the intended meaning of an Alt container or  the meaning defined for the particular property ( s:DistributionSite in this case) and understood by the application An application’s understanding of the intended meaning includes, e.g., that 1 of the members of the Alt container is to be considered as the value of the s:DistributionSite site property

There are ways to describe groups of resources that don’t use the RDF container vocabulary RDF containers are merely provided as common definitions Sometimes there are clear alternatives to using these RDF container types  E.g., a relationship between a particular resource and a group of other resources could be indicated by making the 1 st the subject of multiple statements using the same property See the original example with a bnode for a document as subject of multiple statements with the dc:creator property

Contrast this with, e.g., the following, where it’s the group that’s the agent The resolution was approved by the Rules Committee, having members Fred, Wilma, and Dino. In exterms:. ex:resolution exterms:approvedBy ex:rulesCommittee. ex:rulesCommittee a rdf:Bag ; rdf:li ex:Fred, ex:Wilma, ex:Dino.

The corresponding RDF/XML: <rdf:RDF xmlns:ex=" xmlns:exterms=" xmlns:rdf="

The statements don’t construct containers (as in a programming language data structure)  Rather, they describe containers (groups of things) that presumably exist Similarly, using the container membership properties just describes a container resource as having certain things as members  Needn’t say that the things described as members are the only members

Our examples have illustrated a common pattern in describing containers (regardless of the type of container):  Use a blank node with an appropriate rdf:type property to represent the container itself  Use rdf:li to generate sequentially-numbered container membership properties But RDF doesn’t enforce this way of using the RDF container vocabulary  Could use this vocabulary in other ways. E.g., use a container resource having a URIref rather than use a blank node  And could use the container vocabulary in ways not describing graphs with the "well-formed" structures (as in our examples)

E.g., the RDF/XML on the next slide is similar to the previous example using an Alt container, but  Container membership properties are written explicitly (rather than by using rdf:li )  The container is described as both a Bag and an Alt  It’s described as having 2 distinct values of the rdf:_2 property  It doesn’t have rdf:_1, rdf:_3, or rdf:_4 properties (but does have rdf:_2 and rdf:_5 )

<rdf:RDF xmlns:rdf=" xmlns:s=" <rdf:type rdf:resource=" RDF imposes no "well-formedness" conditions on the use of the container vocabulary  So RDF applications that require containers to be "well-formed" should be written to check that the container vocabulary is used appropriately

RDF Collections There’s no way to close a container, i.e., to say "these are all the members of the container"  And, given a graph that describes some members, there’s no way to rule out another graph somewhere describing additional members RDF collections support describing groups containing only the specified members A collection is a group of things represented as a list structure in the RDF graph  This list structure is constructed using a predefined collection vocabulary consisting of the predefined type rdf:List, the predefined properties rdf:first and rdf:rest, and the predefined resource rdf:nil

Consider the statement The Handbook’s creators are Bill, Ed, and Ken. Assume Bill is identified by URI “  Ed and Ken have similar IDs but with 34 and 46 in place of 21 In exdocs:. dc:creator [ rdf:first exstaff:21; rdf:rest [ rdf:first exstaff:34; rdf:rest [ rdf:first exstaff:46; rdf:rest rdf:nil ] ] ].

The RDF graph firstrest 21 firstrest 34 firstrest 46 handbook creator Represent this as a linked list  The partitioned rectangles represent bnodes  The “ / ” in the last rest field represents the nil resource

Each bnode is implicitly of type rdf:List i.e., implicitly has an rdf:type property whose value is the predefined type rdf:List  Not explicitly shown in the graph  The RDF Schema language defines properties rdf:first and rdf:rest as having subjects of type rdf:List So the info that these nodes are lists can be inferred

One direct translation into RDF/XML represents the bnodes as nested, anonymous rdf:Description elements <rdf:RDF xmlns:exstaff=" xmlns:dc=" xmlns:rdf="

Another way to translate the above N3 into RDF/XML is to use the rdf:nodeID attribute to give IDs to bnodes  Break out the nesting and chain the nodes together <rdf:RDF xmlns:exstaff=" xmlns:dc=" xmlns:rdf="

N3 provides a shorthand for collections:  List all the members (separated by whitespace), enclosed within parentheses The last example can be expressed more succinctly exdocs:. dc:creator (exstaff:21 exstaff:34 exstaff:46).

In RDF/XML, a collection can be described by a property element that  has the attribute rdf:parseType="Collection" and  contains a group of nested elements representing the collection’s members Attribute rdf:parseType indicates that the contents of an element are interpreted in a special way  Here rdf:parseType="Collection" indicates that the enclosed elements are members of a list structure in the RDF graph  Earlier saw that a property element with attribute rdf:parseType="Resource" indicates a bnode

Using rdf:parseType="Collection", we can rewrite the RDF/XML version as <rdf:RDF xmlns:exstaff=" xmlns:dc=" xmlns:rdf="

RDF imposes no "well-formedness" conditions on the use of the collection vocabulary. So, when writing triples in longhand, can define RDF graphs different from the well-structured graphs generated with rdf:parseType="Collection" E.g., can  assert that a node has 2 values of the rdf:first property  produce forked or non-list tails  simply omit part of the description of a collection

And graphs defined longhand can use URIrefs to identify list components instead of blank nodes unique to the list  Then could create triples in other graphs that add elements to the collection  The collection would be non-closed So RDF applications that require collections to be well-formed should check that the collection vocabulary is used appropriately

The following has a node with 2 values for its rdf:first property  Last node in the chain has a non-nil value for its rdf:rest property <rdf:RDF xmlns:exstaff=" xmlns:dc=" xmlns:rdf="

The RDF graph

RDF Reification RDF applications sometimes need to describe other RDF statements using RDF  E.g., to record “provenance” info about a statement: when it was made, who made it, … E.g., an earlier example described a tent with URIref exproducts:item10245, offered for sale by example.com  One triple in that description was exproducts:item10245 exterms:weight "2.4"^^xsd:decimal.  Example.com might record who provided this piece of info RDF provides a vocabulary for describing RDF statements  A description of a statement using this vocabulary is a reification of the statement

The RDF reification vocabulary consists of  the type rdf:Statement and  the properties rdf:subject, rdf:predicate, and rdf:object A reification of the statement about the tent's weight is given by  assigning the statement a URIref, say, exproducts:triple12345, so statements can be written describing it and  describing the statement using the statements: exproducts:triple12345 rdf:type rdf:Statement. exproducts:triple12345 rdf:subject exproducts:item exproducts:triple12345 rdf:predicate exterms:weight. exproducts:triple12345 rdf:object "2.4"^^xsd:decimal. The conventional use of the RDF reification vocabulary always involves describing a statement using 4 statements in this pattern—a "reification quad"

Reification isn’t the same as quotation The reification describes the relationship between  a particular instance of a triple and  the resources the triple refers to The reification says "this RDF triple talks about these things" Quotation, in contrast, provides a piece of language use that we can talk about  E.g., we can refer to its grammatical structure or the denotations of its noun phrases  Quotation by itself doesn’t do this “talking about”

Using reification according to this convention, example.com could record the fact that John Smith made the original statement about the tent's weight by  assigning the original statement a URIref, say, exproducts:triple12345,  describing that statement using the reification just described, and  adding an additional statement that exproducts:triple12345 was written by John Smith Need a URIref to identify the John Smith in question The resulting statements: exproducts:triple12345 rdf:type rdf:Statement. exproducts:triple12345 rdf:subject exproducts:item exproducts:triple12345 rdf:predicate exterms:weight. exproducts:triple12345 rdf:object "2.4"^^xsd:decimal. exproducts:triple12345 dc:creator exstaff:85740.

The RDF graph for these 5 triples plus the original triple exproducts:item10245 exterms:weight "2.4"^^xsd:decimal.

This graph could be written in RDF/XML as ]> <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" xml:base=" 2.4 <rdf:subject rdf:resource=" 2.4 See below

As we’ve seen, the rdf:ID attribute in an rdf:Description element is used to abbreviate the URIref of the subject of a statement  Its value (a fragment identifier) is an abbreviation of the complete URIref of the resource  It’s interpreted relative to a base URI Here the URI of the containing document rdf:ID can also be used in a property element  This automatically produces a reification of the triple that the property element (along with the subject) represents Using this technique, the previous example can be rewritten as in the next slide

]> <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" xml:base=" 2.4

With rdf:ID="triple12345" in the exterms:weight element, we get the original triple describing the tent's weight exproducts:item10245 exterms:weight "2.4"^^xsd:decimal. plus the reification triples exproducts:triple12345 rdf:type rdf:Statement. exproducts:triple12345 rdf:subject exproducts:item exproducts:triple12345 rdf:predicate exterms:weight. exproducts:triple12345 rdf:object "2.4"^^xsd:decimal. The subject of these reification triples is a URIref formed by concatenating  the base URI of the document (see the xml:base declaration),  the character " # " (introducing a fragment identifier), and  the value of the rdf:ID attribute So triples have the same subject ( exproducts:triple12345 ) as before

Asserting the reification isn’t the same as asserting the original statement  Neither implies the other  When I say that John said something about the weight of a tent, I’m not making a statement about the weight of a tent itself Rather, I’m making a statement about something John said  Conversely, when I describe the weight of a tent, I’m not also making a statement about a statement someone made

Applications that successfully use reification do so by  following conventions and  making assumptions that go beyond the meaning that RDF defines for the reification vocabulary

In the conventional use of reification, the subject of the reification triples is assumed to identify a particular instance of a triple in a particular RDF document  This because reification is intended for expressing properties such as dates of composition and source information There could be several instances with the same triple structure in different documents But these properties need to be applied to specific instances of triples  We need some way to associate the subject of the reification triples with an individual triple in some document RDF itself provides no way to do this We need a convention among users

E.g., in the above examples, there’s no explicit info that actually indicates that the original statement describing the tent's weight is the resource exproducts:triple12345  This is the resource that’s the subject of the 4 reification statements and the statement that John Smith created it See the RDF graph above  The original statement is part of this graph  But exproducts:triple12345 labels a separate resource node It doesn’t identify a separate part of the graph (e.g., 2 nodes and an arc connecting them)

RDF doesn’t provide a built-in way to indicate how a URIref like exproducts:triple12345 is associated with a particular statement or graph Similarly, there’s no built-in way of indicating how a URIref like exproducts:item10245 is associated with an actual tent Associating specific URIrefs with specific resources (here statements) must be done outside of RDF E.g., suppose an RDF document (say, a Web page) has a URI  Statements can be made about the resource identified by that URI  Based on some application-dependent understanding of how to interpret those statements, an application could act as if those statements apply equally to all statements in the document

More on Structured Values: rdf:value RDF directly supports only binary relations, i.e., statements of relations between 2 resources E.g., exstaff:85740 exterms:manager exstaff: states that the relation exterms:manager holds between 2 employees But sometimes we must represent info involving relations between more than 2 resources

Earlier discussed the relationship between John Smith and his address info  A 5-ary relation of the form: address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730") Can be represented in RDF by  considering the aggregate thing described (here the group of address components) as a separate resource  then making separate statements about that new resource exstaff:85740 exterms:address _:johnaddress. _:johnaddress exterms:street "1501 Grant Avenue". _:johnaddress exterms:city "Bedford". _:johnaddress exterms:state "Massachusetts". _:johnaddress exterms:postalCode "01730".

A general way to represent any n-ary relation in RDF  Select 1 of the participants (here John) as the subject of the original relation (here address)  Then specify an intermediate resource (usually a bnode) to represent the rest of the relation  Then give that new resource properties representing the remaining components of the relation

For the address, none of the parts is the "main" value of the exterms:address property But sometimes 1 part of a structured value is the "main" value  E.g., in an earlier example, the weight of a certain tent was given as 2.4 using a typed literal exproduct:item10245 exterms:weight "2.4"^^xsd:decimal. In fact, a more complete description of the weight would is 2.4 kilograms (not just 2.4) To state this, the value of exterms:weight needs 2 components  the typed literal for the decimal value (the “main” value of exterms:weight ) and  an indication of the unit of measure (kilograms)

In the RDF model, a qualified property value is considered just another kind of structured value To represent this, a separate resource is used  to represent the structured value as a whole (here the weight) and  to serve as the object of the original statement That resource is given properties representing the individual parts of the structured value Here there’s  a property for the typed literal representing the decimal value and  one for the unit RDF provides a predefined rdf:value property to describe the main value

Here  the typed literal is the value of the rdf:value property and  the resource exunits:kilograms is the value of an exterms:units property (assuming exunits:kilograms is part of example.org's vocabulary) The resulting triples exproduct:item10245 exterms:weight _:weight _:weight10245 rdf:value "2.4"^^xsd:decimal. _:weight10245 exterms:units exunits:kilograms.

Expressed using the RDF/XML ]> <rdf:RDF xmlns:rdf=" xmlns:exterms=" <rdf:Description rdf:about=" 2.4 <exterms:units rdf:resource=" The RDF graph See the next slide

This also illustrates a previous use of the rdf:parseType attribute: rdf:parseType="Resource" Indicates that the contents of an element are to be interpreted as the description of a new bnode resource  without actually writing a nested rdf:Description element Here the rdf:parseType="Resource" attribute in the exterms:weight property element indicates  a bnode as the value of the exterms:weight property and  that the enclosed elements ( rdf:value and exterms:units ) describe properties of that bnode

The approach illustrated 2 slides back can be used to represent  quantities using any units of measure and  values taken from different classification schemes or rating systems Use the rdf:value property to give the main value  Use additional properties to identify the classification scheme or other info further describing the value

The correct interpretation of data in the Web environment may require that additional info (such as units) be explicitly recorded There are alternatives to rdf:value (e.g., a user-defined property such as exterms:amount ) RDF doesn’t associate any special meaning with rdf:value  A convenience for use in these commonly-occurring situations

XML Literals Sometimes the value of a property needs to be a fragment of XML  E.g., a publisher might maintain RDF metadata that includes titles represented with XML elements and attributes To facilitate writing XML literals, RDF/XML provides a 3 rd value of the rdf:parseType attribute  Given an element, the attribute rdf:parseType="Literal" indicates that the contents of the element are to be interpreted as an XML fragment

Using rdf:parseType="Literal", an RDF user avoids dealing directly the various transformations required for representing XML fragments in the accepted (“canonical”) way—e.g.,  Adding declarations of used namespaces  Uniform escaping or unescaping of characters

Example <rdf:RDF xmlns:rdf =" xmlns:dc=" xml:base=" The <br /> Element Considered Harmful. Here rdf:parseType="Literal" indicates that all the XML within the element is an XML fragment that is the value of the dc:title property

The RDF Validator produces 1 triple for this: "<span xml:lang="en"> The <em><br /></em> Element Considered Harmful.</span>" ^^  The object (3 rd element in the triple) here wraps around onto 3 lines As a proper N-triples triple: "<span xml:lang='en'> The <em><br /></em> Element Considered Harmful. </span>" ^^. Where the value of a property may sometimes contain markup and sometimes not, rdf:parseType="Literal" should be used throughout

Given " The <br /> Element Considered Harmful. ". the RDF Validator and Converter produces <rdf:RDF xmlns:rdf=" xmlns:ns=" <span xml:lang='en'>The <em>&lt;br /&gt; </em> Element Considered Harmful.</span>