Re: Comments on Use Case for discussion on telcon

On Tue, Apr 27, 2010 at 5:20 AM, Lee Feigenbaum <lee@thefigtrees.net> wrote:

> 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?
>
>
We would have to make sure that it is explicit in the DDL of some of 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.
>

You state:

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.

This can be a scenario on its own, or where would this fit in the other 4
scenarios that I propose?


>
> Lee
>
>
>>    Lee
>>
>>
>>