Trading perfection for practicality

"McBride, Brian" <> writes:

> Hi Jonas,
> > Statements are not resources.  They do not exist (as resources) in the
> > RDF diagram.  Reified statements was invented as a way to make
> > statements resources, so that we can say things about them.
> Yes.  So in RDF Model terms I presume then that your model container
> contains the resource that represents the statement, not the statement
> itself.  So we might have for example a set of statements:
>   {
>     ([anon:model], [rdf:type], [wraf:model])
>     ([anon:model], [rdf:_1],   [(s, p, o)] )
>   }
> which represents a model containing a single statement (s,p,o).
> This set of statements does not contain the statement (s,p,o).  Yes?


> > Wraf and other RDF implementations automaticly creates a resource for
> > every statement.  This is safe because it doesn't add any information,
> > except that it gives the statement an URI.
> Certainly both my implementations treated statements as resources.  I'm
> curious what URI you generate for your statements.

Just a unique URI in the local namespace.

> > I have no intention to actually write out the reified statements of a
> > model as a RDF/XML serialization.  They just exist there implicitly to
> > let you know what the subject, predicate and object of a specific
> > statement are.  Neither does the container (with it's _1, _2, ...)
> > actually exist.  It's just a way to represent the model in RDF.
> Interesting.  Sounds like you have done the same as I in that I'm
> happy to have the resource which represents a statement without
> explicitly attaching the type, subject, predicate and object 
> properties to it, i.e. an incomplete reification.
> Presumably, if the extra reification statements type,
> subject, predicate and object were explicity part of the model,
> you would write them out and they would show up in query results.
> If I do a query to list all statements with a predicate rdf:_1, what
> answers will I get from WRAF?

I have traded perfection for practicality.  There will be many
generated properties for every resource.  Reified statements are not
the exception.  Transformation rules and other inference rules could
potentially give thousands of properties for a resource.

There are a couple of important points here:

1. The original format of some sort of data are just one of many ways
   to encode the information.  If you look at the information for a
   specific entity, it is encoded as a tree.  The data is stored as but you just ask for!  Transformation rules will give you the answer.  But
   the important thing is that they find the answer then you ask for
   it specifically.  The email will not show if you just ask for a
   list of properties.  

2. You will have many levels of search.  There are no limit of what
   can be infered about a specific resource.  Most of the time, you
   will do fine with a shallow scan.  But sometimes you want more
   details and will instruct for scans.

3. The same interface providing the implicit (dynamic) properties
   should also set up hooks to answer wuestions on those implicit
   properties.  That include questions about list items.

4. But most important.  I think that we have to give up the demand for
   infallibility.  Computers should be able to make misstakes.  They
   can't instantly keep up with changes all around the web.  They
   can't know if the answer is around the next corner.  We can accept
   reasonable correct answers with a reasonable depth.  -- 100%
   correct answers can be reached within a limited domain with a full
   search.  But that could still easily be wrong because we don't know
   if the input is right to begin with.

/ Jonas Liljegren

The Wraf project
Sponsored by

Received on Sunday, 22 October 2000 12:51:08 UTC