W3C home > Mailing lists > Public > public-rdf-wg@w3.org > January 2013

Re: Review of rdf11-concepts ED

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 14 Jan 2013 11:47:55 +0000
Cc: RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <DEE4B9A9-FEF6-4765-8E23-A6634CD79367@cyganiak.de>
To: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Hi Antoine,

Thanks for the careful and detailed review. See below for details on how I addressed your comments.

I don't believe there's anything in my response that should hold up the (long overdue -- mea culpa!) publication of  the draft, so I'm going ahead with the publication request.

On 28 Nov 2012, at 14:22, Antoine Zimmermann wrote:
> Section 1.6:
> The title still has the term "G-boxes"

Okay, removed.

> "As RDF graphs are sets of triples, they can be merged easily" -> why being a set makes merging easier?

As the definition of "merge" in RDF Semantics makes clear, the merge of two RDF graphs is unique. If RDF was, say, a tree data structure, then this wouldn't be the case; there would be many different ways of "merging" two RDF instances. I don't think that the point can be reasonably disputed and therefore doesn't require further explanation.

> "An RDF dataset is a collection of RDF graphs." -> not a collection in the mathematical sense (but not a problem here, more problematic in Section 4).

I don't know what a collection is in the mathematical sense. The word "collection" here refers to the everyday notion.

> "All but one are named graphs associated with an IRI. The last one is the unnamed default graph" -> "The last one" suggests an order on the graphs. Suggestion: "All but one are named graphs, each associated with an IRI.

s/last/remaining/ as per Peter's feedback.

The term "default graph" should stay in the sentence.

> Section 1.7:
> "What graphs exactly are considered to have these relationships is specified by an entailment regime [[RDF-MT]] combined with a datatype map." -> rephrase

Re-wrote the paragraph:

An entailment regime [RDF-MT] is a specification that defines precise conditions that make these relationships hold. RDF itself recognizes only some basic cases of entailment, equivalence and inconsistency. Other specifications, such as RDF Schema [RDF-SCHEMA] and OWL 2 [OWL2-OVERVIEW], add more powerful entailment regimes, as do some domain-specific vocabularies. Some entailment regimes are defined with respect to a datatype map.

> <a title="vocabulary"> -> <a title="RDF vocabulary">


> Section 1.8:
> "A concrete RDF syntaxes" -> "A concrete RDF syntax" or "Concrete RDF syntaxes"
> "different ordering of statmenets" -> statements

Both fixed.

> Section 3.6:
> "See also: IRI equality, literal equality, blank node equality." -> IRI and literal equalities are explicitly defined, but not bnode equality

Now no longer mentions blank node equality.

> Section 4:
> "An RDF dataset is a collection of RDF graphs" -> not in the mathematical definition of "collection"
> Suggestion: "An RDF dataset comprises a collection of RDF graphs and formally consists of:"

As stated above, this refers to the everyday notion. I think that the definition as written is crystal clear, and even a mathematician should be able to understand it without getting confused.

> Section 5.2:
> Instead of "Return domfrag.normalize()", maybe say "The litteral is then mapped to the value returned by domfrag.normalized()."
> Section 5.3:
> same as in Section 5.2

In both cases, the bullet-point algorithm is now prefixed with the following sentence:

Each member of the lexical space is associated with the result of applying the following algorithm:

This works better with the definition of "lexical-to-value mapping" in the beginning of Section 5.

> Section 5.4:
> "It can be seen as a function from IRIs to datatypes." -> rather, it can be seen as a partial function (as a matter of fact, it *is* a partial function)

The statement only says that the members of the domain are IRIs, not that the domain is the set of all IRIs, so the statement is correct as is.

In computer science, a function is *not* a set of pairs, but rather a subroutine of some sort that is independent from the rest of the source code. I don't want to confuse matters by saying that the datatype mapping *is* a function.

> "Other specifications that MAY impose additional constraints on the datatype map, for example, require support for certain datatypes." -> Other specifications MAY (remove "that")


> Section 6:
> "The semantics of fragment identifiers are defined in RFC 3986" -> The semantics ... is defined


> (RFC 3986 defines one meaning of fragment identifiers, right?)

Yes. I mistakenly treated "semantics" as a plural noun, and didn't mean to imply that there are multiple semantics.

> "... RFC 3986 [RFC3986]: They ..." -> they (capital letter only at the beginning of a sentence. A word after colone is not the beginning of a sentence. I realise that there are other occurrences of this error in the document, e.g., Sec.1 ("including: Serialization"), Sec.1.5 ("atemporal: It does not", "following ways: An IRI"), Sec.3.2 ("IRI equality: Two ...", "Relative IRIs: Some", "IRI normalization: Interoperability", "include: Uppercase"), Sec.3.3 ("Literal equality: Two"), Sec.4 ("comprises: Exactly"), Sec.5.5 ("literal is: If the ...").

W3C documents are supposed to be American English, where capitalization after colon is not just permissible but according to many style guides preferred.

> The last two paragraphs are partly redundant.

I don't think so. One talks about constraints imposed by a host language. The other talks about consistency between content-negotiated variants. Those are different issues, even if similar examples are used to illustrate both. Left as is.

Thanks again!


> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 66 03
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
Received on Monday, 14 January 2013 11:49:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:24 UTC