Re: specify the language without reference to implementation; keep inference orthogonal

Dan Connolly wrote:
> I think I have mentioned this in IRC now and then, but I don't
> think I have sent mail about it. Please specify the language
> without reference to implementations.
> That is, take out stuff like:
> "If a query processor encounters a function that it does not provide,
> the query is not executed and an error is returned."
>   $Revision: 1.160 $ of $Date: 2004/12/17 18:16:17 $

Section 11.3:
"Section status: placeholder text - not integrated"

> Stuff like "note that the query processor does not have to have any
> understanding of the values in the space of the datatype" is perhaps
> OK as informal explanation.
> "RDF systems are not required to implement the entailements expressed by
> these rules, but may choose to do so" looks like it refers to some
> standardized notion of "RDF system"; I'm not aware of one. Please
> ground it with a link if there is one. And what does "may choose
> to do so" mean? Does it impact definitions such as Query Results?
> If so, the language isn't well-defined; its definition depends
> on implementations.
> (hmm... where's the term that's like Query Results but factors
> in constraints, optionals, unsaid, and all that?)
> I prefer to get rid of the whole section
> 3.3 Implementation Requirements.

Likely to go anyway but something that discusses the relationship with the 
XSD datatype hierarchy is needed. Suggestions?

> If the WG really wants to get
> into software conformance clauses, (a) it will have a considerable
> impact on our schedule, which is already at risk; I'm not sure
> we can do that without extending the duration of the WG,
> which requires negotiating with various parties outside the WG,
> and (b) the language needs to be specified without reference
> to implementations anyway and (c) we'll need clear
> definitions for the product classes
> (some advice is available in section
> 2.2 What needs to conform of the QA spec guidelines
> This looks like a pretty clear problem:
> "The following are equivalent for a query processor that handles
> preciates for mathmatical expressions:"
> It seems to me that datatype entailments are no different from
> RDFS entailments; some systems pre-compute them and use
> the result as the input graph when evaluating queries. That
> doesn't change how queries work.
> The query written...
> WHERE   ( ?x dc:title ?title )
>         ( ?x ns:price ?price )
>         ( ?price op:numeric-less-than 30 )
> will only match if the input graph includes a triple ala
>  <#x> op:numeric-less-than 30.
> I suggest rewriting "3.4 Constraints and Predicates" to be
> include discussion of RDFS, and making it clear that it's
> informative, i.e. not part of the definition of the query
> language.

3.4 will go - it does not work as it puts literals as subjects into the graph.

suggestions for content welcome.

> I was hoping we could leave the input graph that a service
> chooses fairly opaque for v1, but we don't seem to be
> able to avoid discussing service descriptions or complex
> FROM clauses or something. Hm... I think there's another
> issue brewing...

Received on Wednesday, 22 December 2004 17:19:17 UTC