In RDF what is the best practice to represent data provenance (source)?
BryanJacobson
I want to represent a fact/triple: (Texas population 20851820).
I think I would represent it as follows in RDF:
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:geo="http://www.geography.fake/geo#">
<rdf:Description rdf:about="http://www.geography.fake/geo/Texas">
<geo:population>20851820</geo:population>
</rdf:Description>
</rdf:RDF>
What is the best practice for representing:
* Where this data comes from: (United States 2000 Census).
* Given that populations change constantly, the point in time
associated with this population (April 1, 2000).
If appropriate, go ahead and tell me I should be looking at this
completely differently.
Many thanks!
-- Bryan
Alan Dean
[snip]
> What is the best practice for representing:
> * Where this data comes from: (United States 2000 Census).
You could use <dcterms:references>, see
http://web.resource.org/rss/1.0/modules/dcterms/#references
> * Given that populations change constantly, the point in time
> associated with this population (April 1, 2000).
You could use <dcterms:issued>, see
http://web.resource.org/rss/1.0/modules/dcterms/#issued
I have collated a list of RDF namespaces on del.icio.us, see:
http://del.icio.us/alan.dean/xmlns:
Regards,
Alan Dean
Alan Dean
encoded version
Michael Schneider
Alan told you, which properties you can use to annotate your data.
Note, however, that in RDF you can only add properties to /resources/.
Because you want to annotate /triples/, you first have to regard these
triples as resources. In RDF, this can be done by "reifcation", see:
http://www.w3.org/TR/rdf-primer/#reification
Your example would then need to be extended the following way (note,
that the original definition of ":Texas" must /not/ be deleted,
otherwise you would just talk about some data triple, which does not
really exist):
<rdf:Statement rdf:about="#referenceOfTexasPopulationTriple">
<!-- subject, predicate and object of data triple: -->
<rdf:subject rdf:resource="#Texas"/>
<rdf:predicate
rdf:resource="http://www.geography.fake/geo#population"/>
<rdf:object>20851820</rdf:object>
<!-- annotation of the refied data triple -->
<dcterms:references>United States 2000
Census</dcterms:references>
<dcterms:issued>2000-04-01</dcterms:issued>
</rdf:Statement>
Hint: Above, I used three properties which take literals as their
values:
* 'rdf:object' takes an integer
* 'dcterms:references' takes a name string
* 'dcterms:issued' takes a date
I can make this explicit by telling the used datatype in each case. I
therefore add it as an attribute 'rdf:datatype' to the property tag.
All those datatypes come from the "xsd:" namespace
"http://www.w3.org/2001/XMLSchema#". The names of those datatypes are
"xsd:integer", "xsd:string" and "xsd:date", respectively. For instance,
the above rdf:object tag would then be written as:
<rdf:object
rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">20851820</rdf:object>
If you do not add an explicit datatype, then Semantic Web software will
have to assume that the literal is untyped, which means that it will be
regarded just as a string.
Michael
BryanJacobson
Many thanks, this is exactly what I needed!
Alan, thank you for the dcterms and on the excellent list of RDF
namespaces on del.icio.us.
Michael, thank you for the explanation of using reification (and the
link to the primer) - reification is what I need to do.
I really appreciate the help.
-- Bryan
ch...@bizer.de
RDF reification doesn't work for practical reasons and there are
discussions about removing it from the RDF Spec (see ISWC 2006 Web2.0
panel discussion).
A more current approach are Named Graphs. Please refer to the SPARQL
Specification for details:
http://www.w3.org/TR/rdf-sparql-query/#rdfDataset
Cheers
Chris
Michael Schneider
Chris Bizer wrote on 2006-12-31 in Google Group:Semantic Web:
> Hi Michael,
>
> RDF reification doesn't work for practical reasons
Hi, Chris!
Why is this so? I always had some vague feeling that reification does
not have many friends within the community, but I never found a real
reason for this: Neither a technical reasons, nor a modeling reason.
Technically, there is an obvious drawback in storing space (four triples
used to represent one single reified statement) and computing time, if
reification processing is implemented in a naive way. But, for example,
in JENA, there is special support for reification, as briefly explained
in Section 3.3 of
http://www.hpl.hp.com/techreports/2003/HPL-2003-146.pdf
so I believe there shouldn't be much problems in reality.
In the case of modeling, I would agree that one should not "overuse"
reification. For example,
http://www.w3.org/TR/swbp-n-aryRelations/#RDFReification
talks against using reification for defining n-ary relations. But it
also says what the modeling domain of reification should be:
"The RDF reification vocabulary is designed to talk about
statements—individuals that are instances of rdf:Statement.
A statement is a object, predicate, subject triple and reification
in RDF is used to put additional information about this triple.
This information may include the source of the information
in the triple, for example."
The original poster's question was about that kind of application (see
below): He has some database consisting of triples, and he wants to add
metadata to those triples - acquisition dates and locations - which do
not belong to this database themself. So, I think, using reification in
this case is /a/ working modeling tool for this purpose, and I also
believe that it is /the/ right tool.
Now, you say there are /practical/ reasons. I surly do not have enough
practical experience with reification in real world applications to be
able to either verify or object your statement. So can you please
comment on what problems you (or other people) have found to exist in
practice?
> and there are
> discussions about removing it from the RDF Spec (see ISWC 2006 Web2.0
> panel discussion).
I haven't been at the conf and AFAICS there is no summary on this event
in the proc. But, seriously, I cannot imagine that such a basic feature
of RDF is going to be removed from the spec. It's much too late for this
(AFAIK it has been in since 1999), and there are probably many RDF
applications which would badly break. Also, I personally would miss this
feature...
> A more current approach are Named Graphs. Please refer to the SPARQL
> Specification for details:
> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset
I did not know RDF datasets by now, so I read this section. However, I
am not quite sure if I correctly understand what you mean by pointing me
to this topic. I can see RDF datasets as collections of some non-named
default graph and some additional named graphs. Probably a good thing
for query languages like SPARQL. But for RDF, do you mean that reified
statements, possibly regarded as "single-statement-graphs", are too
restricted, so that reification should be substituted for a generalized
mechanism, by which one is able to annotate complete graphs?
I would have a few things to say on this, but before starting to comment
on my own hypotheses, I first want to here what you really mean.
Cheers,
Michael
Michael Schneider wrote on 2006-12-30 in Google Group:Semantic Web:
>> Hi, Bryan!
>>
>> Alan told you, which properties you can use to annotate your data.
>>
>> Note, however, that in RDF you can only add properties to /resources/.
>> Because you want to annotate /triples/, you first have to regard these
>> triples as resources. In RDF, this can be done by "reifcation", see:
>>
>> http://www.w3.org/TR/rdf-primer/#reification
>>
>> Your example would then need to be extended the following way (note,
>> that the original definition of ":Texas" must /not/ be deleted,
>> otherwise you would just talk about some data triple, which does not
>> really exist):
>>
>> <rdf:Statement rdf:about="#referenceOfTexasPopulationTriple">
>>
>> <!-- subject, predicate and object of data triple: -->
>> <rdf:subject rdf:resource="#Texas"/>
>> <rdf:predicate
>> rdf:resource="http://www.geography.fake/geo#population"/>
>> <rdf:object>20851820</rdf:object>
>>
>> <!-- annotation of the refied data triple -->
>> <dcterms:references>United States 2000
>> Census</dcterms:references>
>> <dcterms:issued>2000-04-01</dcterms:issued>
>>
>> </rdf:Statement>
Chris Bizer
>> RDF reification doesn't work for practical reasons
>
> Hi, Chris!
>
> Why is this so? I always had some vague feeling that reification does not
> have many friends within the community, but I never found a real reason
> for this: Neither a technical reasons, nor a modeling reason.
Some reasons are listed below, others in the Named Graphs journal paper
http://www.websemanticsjournal.org/ps/pub/2005-23
Snip:
RDF reification provides a mechanism for representing meta-information about
triples but tries to stay inside the bounds of a pure triple data model at
the same time. This approach has some substantial drawbacks:
Triple bloat. RDF reification increases the number of triples in an graph
significantly. An effect which is called “triple bloat” [CS04a]. Describing
the elements of a triple using the reification vocabulary causes an at least
threefold increase alone.
Querying reified Statements. It is rather cumbersome to query information
which is represented as reified statements using RDF query languages such as
SPARQL. As a single reified statement is represented by multiple triples,
queries over reified statements also involve multiple triple patterns for a
single statement and therefore quickly become unreadable and confusing.
Figure 4.10 shows a SPARQL query to retrieve all information about people
who have an email address against the reification our example graph. If a
query engine is not especially optimized for this kind of queries it would
answer them slowly, as evaluating multiple triple patterns implies a join
for each pattern [MK03].
Redundant Meta-Information. RDF reification requires metainformation to be
attached separately to each reified statement. This further increases the
size of the graph and might lead to inconsistencies when meta-information is
changed. In order to allow meta-information to be expressed at a higher
level, Graham Klyne proposes to group reified statements together using an
rdf:Bag [BG04] and to attach meta-information to this bag instead of having
to attach it separately to each reified statement [Kly00]. His approach
eliminates redundant meta-information but leave the other problems of
reification untouched, as each original triple is still described by at
least three reification triples plus one extra triple to relate the reified
statement to the bag.
Single Level of Granularity. The RDF reification mechanism allows
meta-information to be expressed only on a single, fixed level of
granularity. Within most information exchange and publication scenarios, RDF
information is provided as graphs consisting of multiple statements. These
scenarios therefore do not require meta-information about individual
statements and it would be more suitable to use a mechanism that allows
meta-information to be expressed at different levels of granularity.
>> and there are
>> discussions about removing it from the RDF Spec (see ISWC 2006 Web2.0
>> panel discussion).
Tim Berners-Lee said on the panel, that reification sucks and that he would
like to have it removed from the spec. I think there is some video coverage
of the panel discussion on the ISWC website, if you want to hear his
original statements.
>> A more current approach are Named Graphs. Please refer to the SPARQL
>> Specification for details:
>> http://www.w3.org/TR/rdf-sparql-query/#rdfDataset
>
> I did not know RDF datasets by now, so I read this section. However, I am
> not quite sure if I correctly understand what you mean by pointing me to
> this topic. I can see RDF datasets as collections of some non-named
> default graph and some additional named graphs. Probably a good thing for
> query languages like SPARQL. But for RDF, do you mean that reified
> statements, possibly regarded as "single-statement-graphs", are too
> restricted, so that reification should be substituted for a generalized
> mechanism, by which one is able to annotate complete graphs?
Yes. Examples of using Named Graphs to represent provenance information and
other meta-information are found in:
http://sites.wiwiss.fu-berlin.de/suhl/bizer/WIQA/index.htm
http://sites.wiwiss.fu-berlin.de/suhl/bizer/WIQA/browser/index.htm
http://www.websemanticsjournal.org/ps/pub/2005-23
http://www.w3.org/2004/03/trix/
> I would have a few things to say on this, but before starting to comment
> on my own hypotheses, I first want to here what you really mean.
I'm looking forward to your comments ;-)
Cheers
Chris
BryanJacobson
reification and alternative approaches.
Michael Schneider
On 09.01.2007 09:15, Chris Bizer wrote:
> Hi Michael,
>
>>> RDF reification doesn't work for practical reasons
>>
>> Hi, Chris!
>>
>> Why is this so? I always had some vague feeling that reification
>> does not have many friends within the community, but I never found
>> a real reason for this: Neither a technical reasons, nor a modeling
>> reason.
>
> Some reasons are listed below, others in the Named Graphs journal
> paper http://www.websemanticsjournal.org/ps/pub/2005-23
Thanks, Chris, for the link, I finally found the time to read it. You
and your co-authors propose an extension to RDF, where it would be
possible to reference complete RDF graphs by name (URI), and so it would
be possible to annotate such a named graph by adding properties to the
URI. I think that this is really a missing feature in RDF, so I
personally appreciate this proposal of named graphs.
To annotate a single RDF triple, you further propose building a
singleton named graph, which contains only this single triple. This
might bring some difficulties with it, because a singleton set is of
course different from its contained instance, but let's forget about
this for now. The issue we are actually discussing in this thread is, if
such a named singleton graph would be an adequate replacement for RDF
Reification. My answer is no, and I will explain, why I think so.
My reason is, in fact, given by yourself in section 3.3 of your paper,
where you say that "RDF reification operates at the semantical level,
not the syntactic". You give an example for this observation: There is
some reified statement
:r a rdf:Statement ;
rdf:subject :s1 ;
rdf:predicate :p ;
rdf:object :o .
and some annotation of ":s1 :p :o"
:r :someAnnotation :x .
Now, when :s1 happens to be the same as some other resource :s2
:s1 owl:sameAs :s2
then, the above ':someAnnotation x' also holds for ":s2 :p :o".
Now I say: This is not a bug, it is a feature! RDF Reification is a
means to describe /relationships/ in the given domain, it is /not/ a
means to describe syntactical RDF triples which denote such
relationships. For example, if you have the triple
alice isMarriedWith bob
in your triple store, you might be interested in telling since when they
are married, in which church the marriage was created, and so on. And if
it turns out that the URI 'bob' denotes the same person as 'robert',
than all those annotation should of course also hold for
alice isMarriedWith robert
So, for such a purpose, you should IMO use RDF Reification!
On the other hand, if you want to say something about the (syntactical)
triple in the graph itself, e.g. that this triple (not the marriage) has
been created in the triple store at 2007-01-17, than a named singleton
graph would be the right thing to use. RDF Reification would be simply
the wrong tool, because it might be that the 'bob' version of the triple
has been stored at another time than the 'robert' version.
The problem is, that, currently, in RDF there is no means to describe
syntactical triples, so RDF Reification is often /abused/ for this
purpose. With named graphs, this bad usage would not be necessary anymore.
What I am saying here is that named (singleton) graphs and RDF
reification are completely complementary, they do not intersect in
functionality, so we cannot drop the one for the other.
Now, the next point to discuss is, what about the annotation of complete
triple /sets/? Say, we have some RDF graph consisting of different facts
about alice and bob. If we want to talk about the RDF graph itself (the
syntactical thing), I would like to use a /named graph/ for this
purpose. But if I had to talk about the /set of relationships/ which
interpret this RDF graph, than named graphs would be the wrong tool.
Below, you cite some proposal where reified statements are collected
within some /rdf:Bag/. This would be an approach I would prefer for the
latter need.
So to summarize: There are actually four different representational use
cases, with four different solutions:
* referencing a (syntactical) triple:
use a singleton named graph!
* referencing a (semantical) relationship:
use RDF reification!
* referencing an (syntactical) RDF graph:
use a named graph!
* referencing a (semantical) set of relationships:
use a bag of reified statements!
Now, I will come to the more technical issues you were mentioning:
> Snip: RDF reification provides a mechanism for representing
> meta-information about triples but tries to stay inside the bounds of
> a pure triple data model at the same time. This approach has some
> substantial drawbacks:
>
> Triple bloat. RDF reification increases the number of triples in an
> graph significantly. An effect which is called “triple bloat”
> [CS04a]. Describing the elements of a triple using the reification
> vocabulary causes an at least threefold increase alone.
Triple bloat is a fact, of course. But I would not regard it as a real
problem, until I have to store a really huge number of reified
statements. As long as there are less than, say, a few millions
of them - and many triple sets in a future SW will probably be that
small - I do not care about space, when there is even enough space left
for this on my cell phone's internal memory. :)
So, what remains, are those really big sets of triple annotations. But,
as I already mentioned in my previous mail, there are already existing
systems which support me to cope with this problem (e.g. JENA). In fact,
a straight forward idea is to just store all those reified statements
physically as quadruples in a relational table, each quadruple component
being an integer referencing that row in the resources table, where the
according URI is placed. This would be a pretty space friendly approach.
When accessing such a reified statement from some triple store, it would
still be seen as a four-triple-per-statement construct, but that would
just be a /view/ to the data.
> Querying reified Statements. It is rather cumbersome to query
> information which is represented as reified statements using RDF
> query languages such as SPARQL. As a single reified statement is
> represented by multiple triples, queries over reified statements also
> involve multiple triple patterns for a single statement and therefore
> quickly become unreadable and confusing. Figure 4.10 shows a SPARQL
> query to retrieve all information about people who have an email
> address against the reification our example graph.
I did not find this Figure 4.10, but what you probably mean is something
like this:
SELECT ?s ?p ?o
WHERE {
?r a rdf:Statement .
?r rdf:subject ?s .
?r rdf:property ?p .
?r rdf:object ?o .
}
This is, of course, somewhat inconvenient, at least when you have to
write it down manually. But, IMHO, this is just a problem with N3/TURTLE
syntax, not with reification itself. What I am missing for long is
special support for reification in N3. Reification would deserve this as
a built-in feature of RDF. Note, that there is some nice syntactical
trick in RDF/XML-ABBREV for existing triples: Just add an attribute
"rdf:ID" to the property tag which should become the predicate of the
reified statement. For N3, well, what about something like this:
`:s :p :o :r` :hasDate "2007-01-11"^^xsd:date .
Here, I use some kind of "quoting syntax" (backticks) to build a
quadruple, where the fourth entry, ':r', would be the URI of the reified
statement. If you just want to create a blank node reified statement,
where the node ID isn't used anywhere else, you could omit the fourth
component, writing:
`:s :p :o` :hasDate "2007-01-11"^^xsd:date .
And this syntax would then of course have to be propagated to SPARQL,
which would make the abouve query more compact.
Just an idea...
> If a query engine is not especially optimized for this kind of
> queries it would answer them slowly, as evaluating multiple triple
> patterns implies a join for each pattern [MK03].
Again, it shouldn't be too hard to do such an optimization. It's at
least easy for a SPARQL parser to match the above pattern of four
triples per reified statement. So, when the writer of such a SELECT
statement learns to write reified statements always in this way (or,
better, in the syntactically-sugared-way I proposed above), the parser
can produce an internal quadruple representation of the form
"[?s ?p ?o ?r]", and then do single lookups in that quadruple table
which I proposed above. That should be reasonable time efficient.
My guess now: If an optimization is reasonably easy to realize, and if
it is important enough (keep in mind that reification is still a core
language feature of RDF), it will probably show up soon in all relevant
triple store implementations (at least soon after it has shown up in the
competitors' triple store implementation :) ).
> Redundant Meta-Information. RDF reification requires metainformation
> to be attached separately to each reified statement. This further
> increases the size of the graph and might lead to inconsistencies
> when meta-information is changed. In order to allow meta-information
> to be expressed at a higher level, Graham Klyne proposes to group
> reified statements together using an rdf:Bag [BG04] and to attach
> meta-information to this bag instead of having to attach it
> separately to each reified statement [Kly00]. His approach eliminates
> redundant meta-information but leave the other problems of
> reification untouched, as each original triple is still described by
> at least three reification triples plus one extra triple to relate
> the reified statement to the bag.
See my discussion above about using this rdf:Bag approach for
representing sets of relationships.
> Single Level of Granularity. The RDF reification mechanism allows
> meta-information to be expressed only on a single, fixed level of
> granularity. Within most information exchange and publication
> scenarios, RDF information is provided as graphs consisting of
> multiple statements. These scenarios therefore do not require
> meta-information about individual statements and it would be more
> suitable to use a mechanism that allows meta-information to be
> expressed at different levels of granularity.
>
>>> and there are discussions about removing it from the RDF Spec
>>> (see ISWC 2006 Web2.0 panel discussion).
>
> Tim Berners-Lee said on the panel, that reification sucks and that he
> would like to have it removed from the spec.
Well, I would really love to see him changing his mind some day
to saying that reification only /mostly/ sucks. ;-)
Best regards,
Michael Schneider
On 18 Jan 2007, Richard Cyganiak wrote:
> On 18 Jan 2007, at 00:32, Michael Schneider wrote:
>>> RDF reification doesn't work for practical reasons
>>
>> Why is this so? I always had some vague feeling that reification
>> does not have many friends within the community, but I never found
>> a real reason for this: Neither a technical reasons, nor a modeling
>> reason.
>
> Here's a real reason. Scenario: provenance tracking.
>
> Michael wants to publish the claim "Reification is great."
>
> Chris wants to publish the claim "That's nonsense."
>
> Richard wants to have both claims in an RDF store and keep track of
> who said what.
>
> First with reification. Michael:
>
> :reification :is :great .
>
> Chris disagrees. So he has to reify the statement and attach a claim
> that the statement is nonsense.
>
> :michael_statement
> rdf:subject :reification;
> rdf:predicate :is;
> rdf:object :great;
> rdf:type :NonsensicalStatement .
Little break here!
Let's see what this expression means from my own point of view: The
statement that Reification is great, belongs to the set of nonsensical
statements. My understanding is that this statement is not about the
specific syntactical triple ":reification :is :great", because one could
for example substitute the URI ":reification" by the URI
:rdfReification, without changing the intended meaning of this
expression (where both, :reification and :rdfReification are considered
to be owl:sameAs). So, in this case, I think I would regard the use of
reification to be the right choice.
> Now Richards wants to load all these statements into an RDF store. No
> problem. He also wants to keep track of provenance; thus he has to
> reify each statement and attach provenance. I will use your proposed
> shorthand notation from earlier in the thread because otherwise it
> would be too tedious:
>
> :reification :is :great .
> :michael_statement
> rdf:subject :reification;
> rdf:predicate :is;
> rdf:object :great;
> rdf:type :NonsensicalStatement .
>
> `:reification :is :great .`
> :asserted_by :michael .
> `:michael_statement rdf:subject :reification .`
> :asserted_by :chris .
> `:michael_statement rdf:predicate :is .`
> :asserted_by :chris .
> `:michael_statement rdf:object :great .`
> :asserted_by :chris .
> `:michael_statement rdf:type :NonsensicalStatement .`
> :asserted_by :chris .
>
> Richard is bothered a little bit by having to reify the reified
> statement.
He could also assign URIs or BlankNodeIDs to each reified statement, and
then refer to them by name, in an analog way as he would reference
named singleton graphs by name.
And, as for named graphs, he does not have to add a ":asserted_by"
property to each single reified statement, if he really want's to
express that the complete statement (consisting of four sub-statements
here) is asserted by Chris. Instead, he could build a rdf:Bag of the
last four above reified statements, and then assign the ":asserted_by
:chris" property to that bag.
The real question here is, if all those ":asserted_by" statements above
are talking about the statements denoted by the triples in :richard's
triple store, or if they talk about those stored triples themself.
That depends on what you want to express here. In the first case, I
would prefer the use of reification, in the second case, I would like to
use named graphs.
> Now imagine if Bob gets into the discussion disagreeing with the
> claim made by Chris; now Richard has to store reified reified reified
> statements. Then Charlie and Dora get into the discussion ... I'm
> tempted to write down the triples just to show that it gets quite
> cumbersome.
If you really want to express such statements about statements about...,
than such a "statement cascade" is the correct modeling approach. Note,
that you effectively do this with named graphs, too! Below, you have
first a named graph ":michael_graph". Than you have another named graph
":chris_graph", which contains some statement talking about
":michael_graph" - first cascade. Then you might have another graph
":bob_graph", which contains a statement about ":chris_graph" - second
cascade, and so on. There is no conceptual difference in this regard to
reification.
And, as for named graphs, you can use names (URIs or BlankNodeIDs) for
(bags of) reified statements, too. So, I cannot see that large advantage
of named graphs in the sense that they would provide much more
convenience than reification. I can see, however, a clear difference in
what can be expressed by both constructs. See next:
> Enter named graphs.
>
> :michael_graph {
> :reification :is_great_for :provenance_tracking .
> }
>
> Chris disagrees:
>
> :chris_graph {
> :michael_graph rdf:type :Nonsense .
> }
>
> Richard's store:
>
> :michael_graph {
> :reification :is_great_for :provenance_tracking .
> }
> :chris_graph {
> :michael_graph rdf:type :Nonsense .
> }
Now, what does the last named graph here express? According to the
introduction of chapter 3 ("Formal Semantics") of [1] (the paper cited
by Chris), the name (URI) of a named graph just denotes that named
graph. So, the statement within :chris_graph above says that the named
graph, which is denoted by the URI ":michael_graph", is in some class
called ":Nonsense". We further use the convention that named /singleton/
graphs should be regarded as the single syntactical triple contained. So
we finally get the following meaning for the statement within
:chris_graph: The syntactical triple
":reification :is_great_for :provenance_tracking"
is a member of the ":Nonsense" class.
But what is meant by a "nonsensical" syntactical triple? Perhaps, it
might be one, for which there is no satisfying interpretation, or
something like that? Whatever the meaning actually is, it is quite
different from the meaning of the above reified statement
":michael_statement".
> :provenance_graph {
> :michael_graph :asserted_by :michael .
> :chris_graph :asserted_by :michael .
> }
>
> And accommodating the contributions of Bob, Charlie and Dora is
> straightforward.
>
> See why reification does not have many friends?
>
> Surprisingly, some people choose to use reification nonetheless. Why
> is this so? Is it just because its unfinished empty concrete shell
> was left in the RDF spec? I never found a real reason, neither
> technical nor modelling.
I want to use RDF reification for referencing a relationship between
resources, in order to describe it by assigning properties. According to
my understanding of [1], I cannot do this with Named Graphs, because
their formal semantics do not allow this.
> Yours,
> Richard
Cheers,
Michael
[1] http://www.websemanticsjournal.org/ps/pub/2005-23