- From: Rob Shearer <Rob.Shearer@networkinference.com>
- Date: Wed, 1 Sep 2004 17:11:48 -0700
- 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