RDF Containers In N3, we could say that Ed (with id 21) and Bill (with id 34) created a certain document as @prefix foaf:. @prefix dc:. @prefix rdf:. @prefix

RDF Containers In N3, we could say that Ed (with id 21) and Bill (with id 34) created a

certain document as

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

@prefix dc: <http://purl.org/dc/elements/1.1/> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix exstaff: <http://www.example.org/staffid/> .

[ 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 a





[ 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 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>

<http://xmlns.com/foaf/0.1/Document> .

_:bnode1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>

<http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> .

_:bnode1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#_1>

<http://www.example.org/staffid/21> .

_:bnode1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#_2>

<http://www.example.org/staffid/34> .

_:bnode0 <http://purl.org/dc/elements/1.1/creator> _: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

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:foaf="http://xmlns.com/foaf/0.1/"

xmlns:exstaff="http://www.example.org/staffid/"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<foaf:Document>

<dc:creator>

<rdf:Bag>

<rdf:_1 rdf:resource="http://www.example.org/staffid/21"/>

<rdf:_2 rdf:resource="http://www.example.org/staffid/34"/>

</rdf:Bag>

</dc:creator>

</foaf:Document>

</rdf:RDF>

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 document





[ 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:A250649 http://www.w3.org/1999/02/22-rdf-syntax-ns#_1

http://www.example.org/staffid/21

genid:A250649 http://www.w3.org/1999/02/22-rdf-syntax-ns#_2

http://www.example.org/staffid/34

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



xmlns:s="http://example.org/packages/vocab#">

<rdf:Description rdf:about="http://example.org/packages/X11">

<s:DistributionSite>

<rdf:Alt>

<rdf:li rdf:resource="ftp://ftp.example.org"/>

<rdf:li rdf:resource="ftp://ftp1.example.org"/>

<rdf:li rdf:resource="ftp://ftp2.example.org"/>

</rdf:Alt>

</s:DistributionSite>

</rdf:Description>

</rdf:RDF>

The graph is

The corresponding N3


@prefix s: <http://example.org/packages/vocab#> .

<http://example.org/packages/X11> s:DistributionSite

[ a rdf:Alt;

rdf:li <ftp://ftp.example.org>, <ftp://ftp1.example.org>,

<ftp://ftp2.example.org> ] .

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 1st 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 N3


@prefix ex: <http://www.example.org/> .

@prefix exterms: <http://www.example.org/terms#> .

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="http://www.example.org/"

xmlns:exterms="http://www.example.org/terms#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<rdf:Description rdf:about="http://www.example.org/resolution">

<exterms:approvedBy>

<rdf:Bag rdf:about="http://www.example.org/rulesCommittee">

<rdf:li rdf:resource="http://www.example.org/Fred" />

<rdf:li rdf:resource="http://www.example.org/Wilma" />

<rdf:li rdf:resource="http://www.example.org/Dino" />

</rdf:Bag>

</exterms:approvedBy>

</rdf:Description>

</rdf: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)



xmlns:s="http://example.org/packages/vocab#">

<rdf:Description rdf:about="http://example.org/packages/X11">

<s:DistributionSite>

<rdf:Alt>

<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/>

<rdf:_2 rdf:resource="ftp://ftp.example.org"/>

<rdf:_2 rdf:resource="ftp://ftp1.example.org"/>

<rdf:_5 rdf:resource="ftp://ftp2.example.org"/>

</rdf:Alt>

</s:DistributionSite>

</rdf:Description>

</rdf:RDF>

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 “http://www.example.org/staffid/21”

Ed and Ken have similar IDs but with 34 and 46 in place of 21

In N3




@prefix exdocs: <http://www.example.org/docs/> .

<http://www.example.org/docs/handbook> 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

first rest

21

first rest

34

first rest

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="http://www.example.org/staffid/"

xmlns:dc="http://purl.org/dc/elements/1.1/"


<rdf:Description rdf:about="http://www.example.org/docs/handbook">

<dc:creator>

<rdf:Description>

<rdf:first rdf:resource="http://www.example.org/staffid/21" />

<rdf:rest>

<rdf:Description>


<rdf:rest>

<rdf:Description>


<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" />

</rdf:Description>

</rdf:rest>

</rdf:Description>

</rdf:rest>

</rdf:Description>

</dc:creator>

</rdf:Description>

</rdf: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






<dc:creator rdf:nodeID="cr1" />

</rdf:Description>

<rdf:Description rdf:nodeID="cr1">


<rdf:rest rdf:nodeID="cr2" />

</rdf:Description>




</rdf:Description>



<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>

</rdf:Description>

</rdf: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 as




@prefix exdocs: <http://www.example.org/docs/> .

<http://www.example.org/docs/Handbook>

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






<dc:creator rdf:parseType="Collection">

<rdf:Description rdf:about="http://example.org/ staffid/21"/>



</dc:creator>

</rdf:Description>

</rdf: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






<dc:creator rdf:nodeID="cr1" />

</rdf:Description>





</rdf:Description>



<rdf:rest rdf:resource="http://www.example.org/staffid/group1"/>

</rdf:Description>

</rdf: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:item10245 .

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 dc:creator exstaff:85740 .

The RDF graph for these 5 triples plus the original triple


This graph could be written in RDF/XML as


<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>



xmlns:exterms="http://www.example.com/terms/"

xml:base="http://www.example.com/2002/04/products">

<rdf:Description rdf:ID="item10245">

<exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>

</rdf:Description>

<rdf:Statement rdf:about="#triple12345">

<rdf:subject

rdf:resource="http://www.example.com/2002/04/products#item10245"/>

<rdf:predicate rdf:resource="http://www.example.com/terms/weight"/>

<rdf:object rdf:datatype="&xsd;decimal">2.4</rdf:object>

<dc:creator rdf:resource="http://www.example.com/staffid/85740"/>

</rdf:Statement>

</rdf:RDF>

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





xmlns:exterms="http://www.example.com/terms/"

xml:base="http://www.example.com/2002/04/products">

<rdf:Description rdf:ID="item10245">

<exterms:weight rdf:ID="triple12345" rdf:datatype="&xsd;decimal">

2.4

</exterms:weight>

</rdf:Description>

<rdf:Description rdf:about="#triple12345">

<dc:creator rdf:resource="http://www.example.com/staffid/85740"/>

</rdf:Description>

</rdf:RDF>

With rdf:ID="triple12345" in the exterms:weight element, we get the original triple describing the tent's weight


plus the reification triples





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:62345 .

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 _:weight10245 .

_:weight10245 rdf:value "2.4"^^xsd:decimal .

_:weight10245 exterms:units exunits:kilograms .

Expressed using the RDF/XML




xmlns:exterms="http://www.example.org/terms/">

<rdf:Description

rdf:about="http://www.example.com/2002/04/products#item10245">

<exterms:weight rdf:parseType="Resource">

<rdf:value rdf:datatype="&xsd;decimal">2.4</rdf:value>

<exterms:units

rdf:resource="http://www.example.org/units/kilograms"/>

</exterms:weight>

</rdf:Description>

</rdf:RDF>

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 3rd 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




xml:base="http://www.example.com/books">

<rdf:Description rdf:ID="book12345">

<dc:title rdf:parseType="Literal">



The Element Considered Harmful.



</dc:title>

</rdf:Description>

</rdf:RDF>

Here rdf:parseType="Literal" indicates that all the XML within the <dc:title> element is an XML fragment that is the value of the dc:title property

The RDF Validator produces 1 triple for this:

http://www.example.com/books#book12345

http://purl.org/dc/elements/1.1/title

" The Element Considered Harmful."

^^http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral

The object (3rd element in the triple) here wraps around onto 3 lines

As a proper N-triples triple:

<http://www.example.com/books#book12345>

<http://purl.org/dc/elements/1.1/title>

" The Element Considered Harmful. "

^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

Where the value of a property may sometimes contain markup and sometimes not, rdf:parseType="Literal" should be used throughout

Given

<http://www.example.com/books#book12345>

<http://purl.org/dc/elements/1.1/title>

"The Element Considered Harmful." .

the RDF Validator and Converter produces <?xml version="1.0"?>


xmlns:ns="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://www.example.com/books#book12345">

<ns:title>

The 

 Element Considered Harmful.

</ns:title>

</rdf:Description>

</rdf:RDF>

Documents

RDF Containers In N3, we could say that Ed (with id 21) and Bill (with id 34) created a certain document as @prefix foaf:. @prefix dc:. @prefix rdf:. @prefix