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

Re: Comments on Last-Call Working Draft of RDF 1.1 Concepts and Abstract Syntax

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Sun, 20 Oct 2013 20:07:31 -0400
Message-ID: <52647043.4060707@gmail.com>
To: Pat Hayes <phayes@ihmc.us>, RDF Working Group <public-rdf-wg@w3.org>

On 10/19/2013 10:01 PM, Pat Hayes wrote:
> My 2c on these comments added inline.
>
> On Oct 19, 2013, at 4:46 PM, Michael Schneider wrote:
>
>> Dear Working Group!
>>
>> This is my review of the Last-Call Working Draft of the "RDF 1.1 Concepts and Abstract Syntax" specification.
>>
>> Unfortunately, I only learnt about the existence of the LCWDs from their announcement on the SWIG mailing list as of 3 October, with an - already extended - deadline set to 17 October, which was a very short time and did not give me enough time to complete the review in time. I hope that you will still accept my review. I will send another review for the RDF Semantics specification, which I will hopefully finish till tomorrow. To ease the process for you, I have, after a mail exchange with Sandro Hawke, created my review based on the most-current editor drafts of the two documents:
>>
>> * <https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html>
>> * <https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html>
>>
>> I'd like to add that I have a high personal and professional stake in these two documents.
>>
>> In general, I consider the "Concepts" document pleasing and don't have any real show-stopping issues to report. Still, there are a few issues that I consider "major", and a couple that I consider "minor".
>>
>> Major issues:
>> -------------
>>
>> *  3.3: "a datatype IRI, being an IRI that determines how the lexical form maps to a literal value." I do not think that it is correct to state that an IRIs would determine how the lexical-to-value mapping works. IRIs generally do only denote some resource, in this case a datatype. It's the datatype specification which determines the mapping, not the IRI that denotes the datatype.
> Correct. Better wording would be "..being an IRI that identifies a datatype which determines..."
Agreed, or "... IRI identifying ...".
>> *  3.1: I believe that the "NOTE" about IRIs, literals and blank nodes being distinct should be formally specified in some way, and not just "noted".
> It should be normative, for sure.

Agreed.  Just move the wording out of the note.
>> *  5.1: Several of the XML datatypes listed seem to be incompatible with the definition of a "lexical-to-value mapping" in the beginning of 5. According to the definition, "each member of the lexical space is paired with exactly one value, and is a lexical representation of that value. However, for example the lexical forms of the datatype "xsd:time" do not uniquely denote a single time value, but denote an infinite number of recurrent time values, one per day (for a fixed time zone). Further, for the datatype "xsd:date", it is not clear whether a lexical form denotes a single point on the timeline (e.g. the starting point of a day), or rather a whole interval of values (the whole day). Variants of these problems exist for several of the other listed time-related datatypes.
> This is all very arguable. The text is however correct in describing what RDF assumes about datatypes. This has some consequences for how the XML datatypes must be interpreted. The value space of xsd:time is the 24-hour daily clock, not timepoints on an infinite timeline. The value space for xsd:date is either points or intervals (if you care, ask the XMLSchema authors), but either way the value is required to be unique for a given lexical form. Variants of these comments apply to the other time-related datatypes.
>
> I propose that we make no changes in response to this comment. The statement is accurate, and to get into this much detail is inappropriate in Concepts.

Agreed.  No change to be made here.
>
>> Minor issues:
>> -------------
>>
>> *  1.2, par 1, states that the term "resource" "is synonymous with entity". I did not find the term "entity" being mentioned elsewhere in the document, nor would I say from my experience that it is widely used in the RDF world as a synonym for "resource". So I suggest to remove the cited phrase.
> Whatever.

Entity is used in three other place in Concepts, but "entity" and "entities" 
could easily be replaced by "resource" and "resources" in Concepts.  However, 
Semantics uses "entity" in eight places without introducting it, so there 
would have to be changes there.
>> *  1.3, 2nd item: double word: "what what
>>
>> *  3.2, the NOTE: "... that permits a much wider range...": the word "much" is redundant and should in my opinion not appear in a specification.
> Agree.
OK.

>
>> * 4.1: In the introductory sentence, the two datasets D1 and D2 each have only a single named graph NG1 and NG2, respectively. This would be unnessesarily restrictive. Therefore, and from condition 6 of the definition, I guess that NG1 and NG2 are really meant to be /sets/ of named graphs for the two datatsets?
>>
>> * 4.1: Typos in condition 4 of the definition:
>>   - comma missing in the set defining G
>>   - the set defining G runs to "1n", which should be "tn" or "Tn"
>>   - the set defining M(G) runs to "M(T(n))": be careful to use the same
>>     term ("tn" or "Tn" that is used in the set defining G.
>>
>> * 5.4: "Semantic *extensions* of RDF MAY recognize other datatype IRIs...". The term "semantic extension" is specific to the RDF Semantics
>>   and as far as I can see does not appear elsewhere in the Concepts document. I think that the sentence should appear only in the RDF Semantics and should be removed in the Concepts document.
Hmm.  I think that this is benign.  It might be better to have "semantic 
extension" point to Semantics, though.
> I have no opinion on the above comments, but the typos should obviously be fixed.
>
> Pat
>
>> Best regards,
>> Michael Schneider
>>
>>

peter
Received on Monday, 21 October 2013 00:08:05 UTC

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