Re: Comments on Use Case for discussion on telcon

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