- From: Juan Sequeda <juanfederico@gmail.com>
- Date: Tue, 27 Apr 2010 02:27:00 -0400
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: public-rdb2rdf-wg@w3.org
- Message-ID: <q2sf914914c1004262327u9d3f5debgb890ed3db9fb828d@mail.gmail.com>
On Mon, Apr 26, 2010 at 10:11 PM, Lee Feigenbaum <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. > 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. > > Lee >
Received on Tuesday, 27 April 2010 06:27:32 UTC