Functional Requirements

[greenTara]

In general, the functional requirements should avoid introducing terms that are undefined or vague, and should not get too specific - they should not anticipate the design. On the other hand, they should not be so general that they have little effect.

In particular, I suggest the following:

1. Stronger: "RDF streams should be representable in an abstract model, and the semantics of this abstract model should provide the basis of the results of RSP queries."

2. Weaker: "The RDF stream abstract model should be serialized in concrete formats derived from standard formats, extending beyond the standard format only when necessary

4. Correction: "RDF streams may have timestamps based on different notions of time (time instants, intervals) with different semantics (application, validity, transactional)."

Re: " In case no timestamp is associated to an RDF stream data item, the system is responsible of managing time-based ordering of stream items." This is something quite different than the earlier part of the requirement, and somewhat controversial. I suggest it be made a separate item and discussed at greater length.

5. Re: "reactively" - what exactly do we mean by this requirement? How does this requirement impose constraints on the abstract model, semantics, concrete language, or query langauge?

7. Greater generality: "RSP engines should be able to query a portion of the knowledge expressed in an RDF stream."

We need a common terminology for the components of an RDF stream: items, elements, members, but please not "events" or "streaming graphs".

9. It is unclear from the wording, but I don't think it is obvious whether the statement includes:

"RSP engines should support combining multiple RDF streams. It could be put into one: "RSP engines should support combining multiple RDF streams as well as stored RDF (aka static RDF graphs or datasets)."

12. More general:

"RSP queries should be able to access all knowledge expicitly expressed in the stream, including names of named graphs and triples containing such names."

13. A window is a stream, so there is no need to have "stream/windows"

[greenTara]

At a higher level, I am wondering about the difference between functional requirements on RSP engines versus the RSP query language. I would have expected that these requirements pertain to the data model and query language, and the essential requirement for RSP engines is that they implement the query language as specified.

[AlasdairGray]

I agree with @greenTara that we should identify the functional requirements for the data model and query language independent of the implementation.

[danhlephuoc]

As mentioned in telco, I think it's good idea to categorise functional requirements into three groups as following:

1. Functional requirements for abstract model and semantics.
2. Functional requirements for query languages and syntaxes
3. Functional requirements for RSP engines

This might make less confusing in collecting functional requirements as well as easier to map the requirements to the work/document/specs has been done.

[greenTara]

I think it will be helpful to have these three groups.

[AlasdairGray]

+1

[greenTara]

There are a number of particular changes suggested above that were not addressed by the pull request or responded to in comments to explain why they would not be adopted.

These are: 2.1.1 #1. Stronger: "RDF streams should be representable in an abstract model, and the semantics of this abstract model should provide the basis of the results of RSP queries." Since the query language requirements have been put into a separate section, that would now be the place to insert a requirement that "The semantics of the query language should be based on the semantics of the abstract syntax" 2.1.1 #2. Weaker: "The RDF stream abstract model should be serialized in concrete formats derived from standard formats, extending beyond the standard format only when necessary" Under the new organization, this would actually be a requirement for the concrete syntax of RDF streams, not for the abstract syntax. This would be a new section in between 2.1.1 and 2.1.2 2.1.2 #4. Correction: "RDF streams may have timestamps based on different notions of time (time instants, intervals) with different semantics (application, validity, transactional)."

Re: " In case no timestamp is associated to an RDF stream data item, the system is responsible of managing time-based ordering of stream items." This is something quite different than the earlier part of the requirement, and somewhat controversial. I suggest it be made a separate item (2.1.2 #5) and discussed at greater length. 2.1.3 #3 . Greater generality: "RSP engines should be able to query a portion of the knowledge expressed in an RDF stream."

2.1.2 #4. More general: "RSP queries should be able to access all knowledge explicitly expressed in the stream, including names of named graphs and triples containing such names."

Generally: We need a common terminology for the components of an RDF stream: items, elements, members, but please not "events" or "streaming graphs".

[beta2k]

Regarding the common terminology: I think it should be either items, or elements. I tend to elements.

[jpcik]

Actually, some of those changes were in branch issue64, which i forgot to merge. That would fix most of those.

[greenTara]

+1 for elements

[jpcik]

changed to elements