Re: Organizing the requirements

I don't know why there is at the current time any need to schedule anything to 
do with SPARQL.  The working group is supposed to produce a non-recommendation 
track document that shows how its approach relates to SPARQL, but that could 
easily be done very late in the process.

peter


On 10/21/2014 12:14 AM, Holger Knublauch wrote:
> On 10/21/2014 16:38, Peter F. Patel-Schneider wrote:
>> I thought that there was this agreement to start from a technology-neutral
>> beginning.  Trying to determine the role of SPARQL before doing use case and
>> requirements analysis does not seem to fit into this agreement.
>>
>> This would be true even if there were universal agreement that SPARQL had
>> the right expressive power.
>
> I fully agree but did not say that we should decide on any technology before
> doing use cases. I only stated that this decision can hopefully be done early
> in the process - once the use cases are collected and analyzed. Without any
> grounding, future decisions become very hard to make. For example the group
> could decide to first develop a completely new language, but this would have
> flow-on effects to the design of the higher-level language for average end
> users and overall lead to a delay in the deliverables. If there was an
> agreement that SPARQL's expressivity is a good match for the catalog of
> requirements, then we can work on the delta that makes SPARQL as useable as
> possible for our scenarios.
>
> Holger
>
>
>>
>> peter
>>
>>
>> On 10/15/2014 06:18 PM, Holger Knublauch wrote:
>>
>> [I have removed the bulk of Holger's message to concentrate on this one
>> particular point.]
>>>
>>> Pragmatically speaking, I believe we should aim at concluding on a key
>>> question early on: the role of SPARQL versus any alternatives. Judging from
>>> the discussions in the old mailing list, I believe many people agree that
>>> SPARQL is the most suitable existing language in terms of expressivity. That's
>>> because SPARQL is a general RDF pattern-matching language and covers the most
>>> common operations with its arithmetic and string manipulation functions. I
>>> don't really see alternatives.
>>>
>
>

Received on Tuesday, 21 October 2014 13:58:41 UTC