W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

RE: Test cases: source of a triple

From: Rob Shearer <Rob.Shearer@networkinference.com>
Date: Wed, 1 Sep 2004 17:11:48 -0700
Message-ID: <CFE388CECDDB1E43AB1F60136BEB497302813B@rome.ad.networkinference.com>
To: "Eric Prud'hommeaux" <eric@w3.org>, "RDF Data Access Working Group" <public-rdf-dawg@w3.org>

But this agnostic approach to SOURCE really just leaves us with yet
another language construct (DESCRIBE being the first culprit) whose
semantics are almost completely undefined. "If you use this feature,
some kind of data will be returned." Frankly, that doesn't seem like
much of a "standard" to me, because the spec doesn't provide enough
information to actually use the feature in any interoperable way.

My preference is to simply leave these features out of the language in
its first incarnation, but I do understand the arguments that people are
going to extend the language in these ways so it would be best if they
did it in some standard way. I don't think publishing a small and
well-constrained spec (hopefully with fully-defined semantics) prevents
us from publishing some supplement saying something along the lines of
"we're expecting the next version to have features that look something
like the following, so if you're extending the language you should
probably use this syntax". It's far from ideal, but if different
implementations are going to have different semantics then I don't
really see how you can do any better than misleading syntactic
compatibility, and I'd rather we were up front about what is such a hack
and what isn't.

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org 
> [mailto:public-rdf-dawg-request@w3.org] On Behalf Of Eric 
> Prud'hommeaux
> Sent: Wednesday, September 01, 2004 5:00 PM
> To: RDF Data Access Working Group
> Subject: Re: Test cases: source of a triple
> On Fri, Aug 27, 2004 at 10:28:40AM +0100, Steve Harris wrote:
> > 
> > On Thu, Aug 26, 2004 at 06:37:58 +0100, Andy Seaborne wrote:
> > > My next example (3) then highlights an interaction of 
> SOURCE and inference
> > > if we attempt to use the natural result from case 2.  
> Others advocate that
> > > SOURCE reflect the origin graph in the aggregation.  What 
> if it can arise
> > > across the aggregations? Are we saying that inference 
> *can't* be done in
> > > this case?
> > 
> > I havent seen anyone else argue for inferred triples being 
> the the graph
> > of one of the ground triples that lead to the inference. It 
> seems like an
> > odd decision.
> > 
> > If you place inferred triples in another SOURCE/graph (which seems
> > reasonable to me) then these problems go away.
> I propose that we not worry about where the inferences go -- leave
> that to the various engines. They can associate them with whatever
> URI or bnode they want. Further, they can add a bunch of proof
> properties if they want. Some group can define those properties
> after they've been better explored, just as they could say that
>   SOURCE ?foo (?p ?s ?o)
> really means
>   ?rt rdf:predicate ?p.
>   ?rt rdf:subject ?s.
>   ?rt rdf:object ?o.
>   ?rt rdf2:label ?foo.
> By defining a syntax by which our language gets at this provenance
> data, we get to duck the hard questions of how that provenance data
> projects into the RDF world. Call me a coward, but that seems like
> a good idea to me.
> -- 
> -eric
> office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
>                         Shonan Fujisawa Campus, Keio University,
>                         5322 Endo, Fujisawa, Kanagawa 252-8520
>                         JAPAN
>         +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +1.857.222.5741 (does not work in Asia)
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose 
> other than
> email address distribution.
Received on Thursday, 2 September 2004 00:14:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC