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

Re: Test cases: source of a triple

From: Eric Prud'hommeaux <eric@w3.org>
Date: Wed, 1 Sep 2004 23:25:41 -0400
To: Rob Shearer <Rob.Shearer@networkinference.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20040902032541.GC14292@w3.org>
On Wed, Sep 01, 2004 at 05:11:48PM -0700, Rob Shearer wrote:
> 
> 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.

I think interoperability is best served if we make provisions in this
version of the vocabulary (so folks don't have to do it themselves)
and let the grounding in the RDF graph work itself out. "We're
expecting it to look like this" runs a close second, to my mind. In
either case, we'll have to work out the grammar in advance.

Your approach would save us some time on the specs and the test cases,
but I think the folks that currently rely on this will want test cases
that promote interoperability of their use cases.

> > -----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.
> > 

-- 
-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 03:25:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:20 GMT