Re: Target audience of the Direct Mapping document?

Hi Alexandre,

On 8 Jul 2011, at 21:37, Alexandre Bertails wrote:
> This "formal stuff" is actually very accessible, both the formalism
> itself and its syntax

What is the basis for this assertion?

> *All requirements* are in the document (at least for section 3.)

No, Alexandre, they are not.

What is a "common SQL datatype"?

What is a "lexical value"?

What is a "candidate key"?

> and you clearly don't need a PhD to understand them.

Alexandre, I didn't ask about PhDs.

I asked about first-year students and about domain experts without maths background or DB background. They are part of the intended audience, according to Eric, or would you disagree with that? Is the style of Section 3 appropriate for such an audience?

> The credibility of this definition was ensured by the work of this Working Group as well as the researchers who proof-read our K-CAP paper, used to that king of stuff.

I don't know how the opinion of these researchers is relevant to this discussion, as they are not the target audience, according to Eric.

> So I can safely say that we made sure that the technical barrier was
> very low.

You made sure that the technical barrier is very low by having researchers proof-read a paper about the direct mapping?

I think you may be going about this the wrong way.

>> but the couple examples should allow them to predict the graph well enough to use it.
>> 
> 
> I'd say that the English version coming along each definition/rule is
> enough.

I find the English version *very* helpful for parts 3.1 to 3.3.

I find the English version useless for 3.4, except in the parts where it states things that are not stated in the maths. In 3.4, it is merely commentary on the maths, and *not* an alternative plain English expression of the maths. This should be fixed.

> For example, we know formally that the mapping goed through any RDB instance, thanks to the
> static checking in the Scala implementation. This is a requirement for a so-called mapping, and we have it for free (at least for section 3.).

Static type checking didn't save you from writing [42] and [48] which are incapable of producing IRIs that are compatible with [33], meaning that your mapping cannot *ever* produce a correct RDF graph, except for an empty database. So I hesitate to put much trust in static type checking.


Could you please add to the document:

1. A normative instruction that states that clicking the "Show English Syntax" button is normative

2. A normative instruction that states that clicking the "Hide Set-Style Syntax" button results in an incomplete rendering of the Direct Mapping

3. A normative instruction that states that neither the "English Syntax" nor the "Set-Style Syntax" are complete on their own

4. Something to explain that the squiggle is pronounced "Phi"

5. A proper reference for "IWD 9075-14:2011(E)", Google can't find it

6. An account of how row IRIs and row blank nodes are created (maybe I'm just stupid but I can't find it anywhere in Section 3)

7. An account of what the syntax "let abc = xyz in" means. I can't figure it out. Is this Scala syntax? If so, can you please add a normative reference to Scala and state in the Introduction that knowledge of Scala syntax is required?

8. Explain to me why there's a "table(r)" in "⟦table(r), c⟧col" and "⟦table(r), fk⟧col". Shouldn't the static type checking catch errors of this kind?

9. State that Datatype in [9] includes String (you explicitly check for String later)

10. Do something about the fact that String in [9] and String in [10] are something different

11. Replace the reference to WSDL with a reference that explains how to percent-encode strings (it only explains, VERY badly, how to encode sets of name-value pairs)

12. Use a reference for percent-encoding that is Unicode compatible (SQL column and table names are Unicode strings)

13. Clarify whether tables includes views or not

14. Clarify whether a Database is the set of tables in a Schema or the set of tables in a Catalog (or some other set of tables)

15. Make this a grammatical sentence: "A statement between a row and a foreign key, telling if the absence of NULL values"

16. Explain what the notation "(columnNames, _, _)" means

17. Explain the significance of difference between the "foo(bar)" notation that is sometimes used, and the "[[bar]]foo" notation that is used at other times

18. Change the column IRIs so that it produces valid RDF IRIs, rather than relative IRIs

19. Fix the typo in "langageTag" and make it link somewhere proper

20. Remove candidateKeys which is defined but never used

I'll stop here and withdraw my earlier assertion that Section 3 may be ready for Last Call.

Received on Saturday, 9 July 2011 18:27:05 UTC