Re: RDF 1.1 Primer

Hi all,

as per my action last week, here is my review of the Primer :

* section 1, issue 2 "do we really need a roadmap section..." I think not.

* section 3 : unlinke Pat, I'm ok with the "informal" examples, but it
should probably be made clearer that it is what they are, informal. This is
probably an occasion to present the notion of abstract/concrete syntax.
** may be the pointy brackets should be replaced by quotes, making the
terms less IRI-like, and so more obviously informal
** <This video document> didn't please Pat; I'm assuming that the word
"This" is contributing to that, as it may be interpreted as a self
reference to the graph at hand? How about "That video document"?

* section 3.3 "The RDF Concepts document provides a list of datatypes" : I
would add "a (non exhaustive) list of datatypes", (with the parenthesis) to
prevent the wrong interpretation that those datatypes are the only ones
usable with RDF

* section 3.4 Bland nodes : I share most of Pat's concerns in this section
** "anonymous resource" is misleading, it reads indeed as a different kind
of resource; I would rephrase in the spirit of "resources for which we
don't have nor want to create an IRI"
** I agree with Pat that the example is unlikely... I like his example with
the Cypress.
** I also find it a bit extreme to state that blank nodes are rarely used
or should not be used; this note should probably be removed; it really the
account of blank nodes in Concepts or Semantics is deemed "scary", such a
reassuring note should be present in *those* documents

* sectio, 3.5 Multiple graphs: is it intended that the examples IRIs are
sometimes in example.com, and sometimes in example.org ? If there is a
reason to it, it should be made clearer. If not, then this should probably
be removed.

* section 4 RDF Vocabularies :
** I agree with Pat that FOAF (or any other vocabulary) should not be
called a schema. A disambiguation note would probably be useful here,
explaining that the term "schema" in the RDF world does not mean the same
as in the XML or RDB world, and should probably never have been used in the
first place, as it is often *very* misleading, as my next remark shows.
** "subject and object of this property must be resources of class
ex:Person" is misleading. Replace "must be" by "is". The current phrasing
reads like it would be illegal to state <#bob> foaf:name <#alice> and to
*not* state that <bob> a foaf:Person. This is a very common
misunderstanding about RDFS, so we must be very careful not to give this
impression.
Just below, you write "to model groups of resources that can act as subject
or object". This (the word "can", especiallyà is misleading again, as no
resource is ever forbidden to act as subjet or object of any property.
Furthermore, I agree with Pat that this phrasing is strange, and I like his
proposal better.

* table in section 4 : I propose that the syntactic form for Class be "s
rdf:type rdfs:Class", and that the description be "s is and RDF class".
Same for property. Agreed, this is a shortcut (rdfs:Class can technically
be used in other triples) but it is more homogeneous with the rest of the
table, and in my opinion easier to grasp.

* section 5.1 Turtle, paragraph aboutl lines 1-6
** IRI should be used instead of URI
** "The "base" prefix is used if no prefix is provided" this is misleading;
the base prefix is used for relative URIs inside pointy brackets, while
prefixed names have no brackets. I would rephrase the whole section in the
following spirit :

'In Turtle, IRIs are enclosed in pointy brackets <>. Relative IRIs are
resolved agains a base IRI, specified in line 1.
'The following lines define IRI prefixes (such as foaf:), that can further
be use prefixed names (such as foaf:Person) instead of full IRIs.
'The corresponding IRI is constructed by replacing the prefix with its
corresponding IRI (in this example, foaf:Person stands for <
http://xmlns.com/foaf/0.1/Person>).

Also, would'nt it be better to use SPARQL-like prefixes, as they are
compatible with SPARQL, precisely? (but granted, they would break
compatibility with older Turtle parsers, so I'm not sure about it).

* section 5.1 Turtle, paragraph about line 9 : I would elicit the fact that
it should be read "bob (is) a Person"

* section 5.1 Turtle, paragraph about string literals : why not use the
string "Leonardo da Vinci" as an example, since it is present in the
example? And furthermore, it is confusing afterwards to use "Leonardo da
Vinci"@it as an example, as it does not appear in the example. Or should
it? Finally, in "The datatype of language-tagged strings is not specifed
explictly in Turtle", I would replace "not" by "never".

* section 5.3 Other concrete syntaxes : it is not true that RDF/XML was the
only official concrete syntax: RDFa was already recommended by the W3C.

* section 6  Semantics : not sure what you plan to do with the ex:Marriage
example, but I'm affraid this is a very exotic feature that will not appeal
to many readers. A more interesting feature (IMO) would be to show how a
resource can be treated both as a class and as an instance.

* Annex A : I didn't check if all the examples provided the same data as
the Turtle (resp. Trig) example, but that would be a good idea. It seems
that the multi-graph JSON-LD does not contain the triples from the default
graph.

* Annex A.2 : I think a third example, using "simple" JSON with a slightly
more complex @context, would nicely illustrate how JSON-LD can leverage
"idiomatic" JSON to RDF. If you think that is a good idea, I volunteer to
write that example.

  pa


On Wed, Nov 20, 2013 at 12:21 AM, Guus Schreiber <guus.schreiber@vu.nl>wrote:

> All,
>
> Yves, and I think that the Primer is ready for a first round of review
> by the WG. The Editor's Draft is here:
>
>    https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-primer/index.html#
>
> We are still working on Sec. 7 (RDF Data), but would welcome comments on
> the rest.
>
> Guus
>
>