Re: Statements/Reified statements

Sergey Melnik wrote:
> 
> Jonathan Borden wrote:
> >
> > Sergey Melnik wrote:

<snip />

> >     By merging into one, do you mean drop the notion of statement
> > reification? If a statement and a reified statement are the same thing, I'm
> > sure loads of people would prefer forget reification exists.
> 
> Don't drop reification, it's heavy ;) I'd rather make it a lightweight
> built-in feature by explicitly making every statement a resource.

I hope others will weigh in here but it seems clear that there is a
difference between the statement (member of Statements) and the
reified statement in the model. This is used to distinguish between
stating and quoting as others have said. It is explicitly part of the
specification. How do you track quotings, i.e. the reification
resource is explicitly present in the data source but the ground
statement is not? 

I empathize with the desire to make reification lightweight but I see
replacing the triple with a quad (ReificationResource, subject,
predicate, object) in the _implementation_ as being a good candidate
for this. The quad represents the resource of type RDF:Statement (I'll
just say RDF:Statement from hereon in as short-hand for the resource
of type RDF:Statement) that needs to be generated for every statement
that occurs in the source document (according to the spec). 

There also needs to be a way to distinguish between the quoting
RDF:Statements and stating RDF:Statements. I see two ways of doing
this. One is to encode the information in the URI of the
RDF:Statement. This will still not work in the case that the data
source is explicitly creating both stating and quoting reification
resources. The second way is to add information, either in-band in the
model, or out of band in the implementation. I tend to prefer the
in-band approach since it allows the information to standardized
across implementations. 

As an example of this, I can imagine that a processor would generate
additional bags hanging off of the top level resource representing the
data source that would capture information like which RDF:Statements
were quotings. 
 
<snip />

> > > The M&S spec clearly states that statements are *non-atomic* entities in
> > > the RDF model, i.e. they have 3 identifiable parts. Why then getting
> > > into trouble of defining another mechanism ("quad reification") for
> > > identifying these same parts in a less efficient (in all senses) manner?
> >
> >     In order to assign a URI to a triple.
> 
> Why not make it computable if necessary (Skolem)? Can save a lot of
> space...

I haven't looked at your more recent work, but my impression was that
the function required a complete model and could require a
recalculation of the ID whenever statements were added or removed. Is
this the case? 

<snip />

> Sergey

Gabe
-- 
--------------------------- 
http://www.jfinity.com/gabe

Received on Wednesday, 22 November 2000 22:22:30 UTC