- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 27 Apr 2010 05:20:48 -0400
- To: Juan Sequeda <juanfederico@gmail.com>
- CC: public-rdb2rdf-wg@w3.org
On 4/27/2010 2:27 AM, Juan Sequeda wrote: > > On Mon, Apr 26, 2010 at 10:11 PM, Lee Feigenbaum <lee@thefigtrees.net > <mailto:lee@thefigtrees.net>> wrote: > > On 4/26/2010 8:27 PM, Juan Sequeda wrote: > > > The other two use cases, Exposing many-to-many join tables as simple > triples and Value based type specification, I honestly do not see > them as use cases, instead as a motivation for requirements. > > > Well, yes, they are use cases that drive certain requirements that I did > not see explicitly covered by other use cases. To me, the primary goal > of identifying use cases is to drive requirements. In turn, requirements > drive a coherent and useful specification. Do I misunderstand the goal > of this document? > > > The other use cases do not specifically express that you need to expose > many-to-many join tables as simple triples or value base type > specification, but I'm sure that it will be part of the whole approach. > I can assure you that in one of our papers we give the semantics of > translating a many-to-many join table as triples. Are there requirements that cover these two bits of expressivity that derive from the other use cases? > My organization's uses of this technology all fall broadly under the > category of needing to expose RDB data to tools that consume data > via arbitrary SPARQL queries. As such, I do not have one (or a fixed > number) of schemas or scenarios that drive my requirements. Instead, > I have expressivity, implementation, and tooling requirements, many > of which are covered by other use cases, but some of which were not, > and are instead covered by these two use cases. Is there a way in > which these are deficient? > > > > Lee, I propose that you write a use-case that your company has and this > may lead into a scenario 5. Can you explain what you mean? I thought that's what I _had_ done. I'm not at liberty to write-up actual customers' database schemas, which is why I simplified these use cases to the relevant (to us) points. Lee > > Lee > >
Received on Tuesday, 27 April 2010 09:21:32 UTC