RE: Best way to assert that "s p o" was true at time t?

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Thomas B.
> Passin
> Sent: 10 October, 2004 04:38
> To: www-rdf-interest@w3.org
> Subject: Re: Best way to assert that "s p o" was true at time t?
> 
> 
> 
> Charles McCathieNevile wrote:
> > [Bcc www-rdf-calendar@w3.org 'cause this touches on them.]
> > 
> > All of these suggestions seem to answer the actual 
> question, not the one
> > hinted at in the subject line.
> > 
> > Two more ideas to consider:
> > 
> > One is that you make a bunch of statements in a document, 
> and you then
> > describe when that document is "valid" (or just date it as 
> a claim made at
> > time t).  
> 
> 
> This problem is at bottom equivalent to the problem of representing a 
> subgraph.  Once that problem is solved in a satisfactory way, 
> many, many 
> questions such as this one will able to be handled.

Yes. I had thought to mention named graphs, but took the original
question as asking about how to do this *now*, with the existing
RDF machinery supported by existing tools.

While there are some tools emerging that support named graphs,
they're still in their infancy, and I tend to avoid suggesting
solutions based on too-new machinery.

Many folks may not care much for reification, but it's there and
it does work. We use reification ourselves at Nokia to qualify
the relevance of certain assertions, which is quite similar to
qualifying an assertion per a specific timeframe.

> As an example, Sowa in various of his writings (including his 
> Knowledge 
> Representation book from 2000) shows assigning a "point in time" to a 
> "situation". See, for example, p. 174 and p. 208 of the KR book. 
> Looking at the "situation" in fig. 4.1 on p. 208, it is 
> obvious that the 
> "situation" is a subgraph (the diagram depicts a conceptual 
> graph rather 
> than an rdf graph, but the same principle obviously applies).
> 
> Once we can refer to a subgraph, then, we can assign it an effective 
> time, or whatever we want along those lines.

True. But I see qualfications of graphs are just a convenient
way of qualifying each statement in that graph individually.
I.e., one can infer reifications based on statements made about
the graph, and one's application can test reifications as an
atomic form of expression -- irregardless of whether the 
reifications are persistently stored or dynamically inferred.

E.g.

IF  
   ?g ( ?s ?p ?o ) .
   ?g ex:context ?x .
THEN
   _:s rdf:type rdf:Statement .
   _:s rdf:subject ?s .
   _:s rdf:predicate ?p .
   _:s rdf:object ?o .
   _:s ex:context ?x .

and the application/agent would be making decisions based on

IF
   ?s ?p ?o .
   ?stmt rdf:type rdf:Statement .
   ?stmt rdf:subject ?s .
   ?stmt rdf:predicate ?p .
   ?stmt rdf:object ?o .
   ?stmt ex:context ex:someParticularValidContext .
THEN
   ?stmt rdf:type ex:ValidStatementToBeConsideredRelevant .

This really is the same for any use cases whereby an agent
filters knowledge based on various qualifications. E.g.

IF  
   ?g ( ?s ?p ?o ) .
   ?g ex:source ?x .
THEN
   _:s rdf:type rdf:Statement .
   _:s rdf:subject ?s .
   _:s rdf:predicate ?p .
   _:s rdf:object ?o .
   _:s ex:source ?x .

and then

IF
   ?s ?p ?o .
   ?stmt rdf:type rdf:Statement .
   ?stmt rdf:subject ?s .
   ?stmt rdf:predicate ?p .
   ?stmt rdf:object ?o .
   ?stmt ex:source ?x .
   ?x rdf:type ex:aTrustedSource .
THEN
   ?stmt a ex:ValidStatementToBeConsideredRelevant .

etc, etc....

But in either case, the necessary knowledge to sift through various
assertions and decide which are relevant/valid for a given operation
has nothing to do with how one obtains that knowledge.

URIQA is a perfectly sufficient (IMO ideal) solution for facilitiating
access to *any* knowledge which is relevant to a given agent.

If some particular agent draws incorrect conclusions from knowledge
obtained from another agent because it does not fully understand all
of the terms used to express that knowledge, then that is certainly
a problem -- but *not* with the machinery used to interchange the
knowledge itself.

> It would be best of everyone used the same way of referring to 
> subgraphs, since this would allow the largest number of processors to 
> know how to work with the subgraph idiom.  Since we don't 
> have a single 
> accepted way to do this, people have to keep trying to roll their own.

Agreed.

> So far, I've only seen two ways that seem to me to be reasonably 
> feasible, to represent the intended meaning clearly, and also not to 
> require any change to the current rdf Recs -
> 
> 1)  Create a document that contains just the subgraph of interest. 
> Assign it a URI, and invent a predicate for referring to that 
> URI.  The 
> trouble is that you have to create and maintain a document 
> (which may be 
> virtual, i.e., generated when requested, or an actual physical 
> document), and the new predicate has to be widely understood. 
>  Actually, 
> we need both a new resource type, the "subgraph", and a 
> predicate that 
> says that a subgraph is found at a particular retrievable uri.

And since a graph and a subgraph are both resources, and any
resource can be denoted by a URI, we can use the existing
web machinery to name, describe, and publish those resources.

I don't think we need an explicit class 'subgraph' though. E.g.

   <http://example.com/graph1> a ex:Graph .
   <http://example.com/graph2> a ex:Graph .

   <http://example.com/graph2> 
      dc:partOf 
         <http://example.com/graph1> .

and then

   GET /graph1
   Host: example.com

could return an RDF/XML representation of the entire graph, and

   MGET /graph1
   Host: example.com

could return an RDF/XML description of the graph which may very
well include statements about the graph not included in the graph
itself, including statements about scope, signatures, etc. And since
the description is authoritative, an agent can equate the authority
of the description graph (and then subsequently of the representation
graph) with the web authority of the URIs via which that knowledge was 
obtained.

The description of course itself constitutes a graph, which would
need a distinct URI from that of the graph it describes, e.g.

   <http://example.com/uriqa?uri=http://example.com/graph1>
      rdf:type
         uriqa:Description .

etc.

> 2) Make each predicate in the subgraph an individual with its 
> own uri. 
> The subgraph would then be represented by a simple collection 
> of all its 
> individual predicates.  That collection could naturally be 
> given its own 
> uri.  The problem with this approach is that it might not 
> play well with 
> various forms of DL processing, and, of course, you are creating more 
> individuals.  But there is nothing in rdf itself that would 
> prevent this 
> approach.

I think this approach would also be very cumbersome to do manually,
but would require some kind of automation, whereby one graph was
derived from another such that each predicate in the source graph
was replaced by a new context+origpredicate in the second graph.

Approach 1 would be much easier, I think.

> I don't see the reification approach in Charle's post as being a real 
> solution, partly because a reified statement is not asserted 
> in rdf in 
> the same way as a "real" triple, but more because the real-life 
> situations that need to be qualified by their times, or 
> otherwise talked 
> about, are usually going to be more complex than just one triple. 
> That's why we need to be able to make statements about a subgraph.

Both good points. 

Though, as stated above, reifications can be used now, and then later
combined with named graphs when support for names graphs matures,
simplifying the qualification of sets of statements.

As for the issue of assertion. One could streamline the above use
case by defining a subclass of rdf:Statement which is the set of
all assertions (triples) not just statements. E.g.

   ex:Assertion 
      rdfs:subClassOf rdf:Statement ;
      rdfs:comment "The class of all RDF assertions (triples) .

such that both of the following rules hold:

IF
   ?s ?p ?o .
THEN
   ?a rdf:type ex:Assertion .
   ?a rdf:subject ?s .
   ?a rdf:predicate ?p .
   ?a rdf:object ?o .

IF
   ?a rdf:type ex:Assertion .
   ?a rdf:subject ?s .
   ?a rdf:predicate ?p .
   ?a rdf:object ?o .
THEN
   ?s ?p ?o .

then we can streamline the above use case as

IF  
   ?g ( ?s ?p ?o ) .
   ?g ex:context ?x .
THEN
   _:s rdf:type ex:Assertion .
   _:s rdf:subject ?s .
   _:s rdf:predicate ?p .
   _:s rdf:object ?o .
   _:s ex:context ?x .

and the application/agent would be making decisions based on

IF
   ?stmt rdf:type ex:Assertion .
   ?stmt ex:context ex:someParticularValidContext .
THEN
   ?stmt rdf:type ex:ValidStatementToBeConsideredRelevant .

etc.

Cheers,

Patrick

Received on Sunday, 10 October 2004 08:25:30 UTC