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

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

From: Michael Schneider <schneid@fzi.de>
Date: Mon, 21 Oct 2013 23:35:57 +0200
Message-ID: <52659E3D.6060304@fzi.de>
To: David Wood <david@3roundstones.com>
CC: "public-rdf-comments@w3.org Comments" <public-rdf-comments@w3.org>, "Markus Lanthaler" <markus.lanthaler@gmx.net>
Hi David,

in summary, I am pleased with all your changes. See below for the 
details, where given.

Am 21.10.2013 20:36, schrieb David Wood:
> Hi Michael,
>
> Thank you for your careful review of RDF 1.1 Concepts and Abstract Syntax.  This message constitutes an official response from the RDF WG.  We are tracking your comments in our  ISSUE-161 [1].
>
> On Oct 19, 2013, at 17:46, Michael Schneider <schneid@fzi.de> 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.
>
>
> The wording now reads:
> [[
> a datatype IRI, being an IRI identifying a datatype that determines how the lexical form maps to a literal value.
> ]]
>
> Does that work for you?

Agreed.

>> *  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".
>
>
> Good catch.  The "note" marker has been removed so that paragraph is now normative.

Thanks.

>> *  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.
>
>
> We discussed this at length and decided that, although your points are interesting, the text in Concepts is currently correct in describing what RDF assumes about datatypes. This has some consequences for how the XML datatypes must be interpreted. We have made no changes because to get into this much detail is inappropriate in Concepts.
>
> You may wish to take this up with the XML Activity.

Actually, I did not critizise the text what RDF assumes about datatypes, 
but I thought that there would be a discrepancy between that text and 
the particular selection of datatypes: I believed that for some of the 
listed datatypes their lexical-to-value mapping would not be a function, 
that is, would not map each lexical form to a single value. But after 
checking the XML Datatypes spec, I see that the lexical-to-value 
mappings there are indeed meant as functions. It is just that the data 
"values" are not always single unique points on the time line, but can, 
for example in the case of xsd:date, be whole intervals. While this may 
turn out to have consequences for the implementation of complete 
D-entailment reasoners, my original point appears void now.

So I'm ok with the decision.

>> 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.
>
>
> The phrase has been changed to read:
> [[
> the term is synonymous with "entity" as it is used in the RDF Semantics specification
> ]]
 >
> This is partly to avoid unnecessary editorial changes in Semantics.

I haven't cross-checked between documents, so I haven't found this. I 
can now see that the term is indeed used a few times in the RDF 
Semantics, and although I would rather opt to replace it there, so that 
there is only a single term to be used throughout for the same notion, 
your change is acceptable.

>> *  1.3, 2nd item: double word: "what what"
>
>
> Fixed.

Ok.

>>
>> *  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.
>
>
> "much" has been removed.

Thanks.

>>
>> * 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?
>
>
> Yes, I can see where you might read it that way.  The sentence now starts:
> [[
> Two RDF datasets (the RDF dataset D1 with default graph DG1 and any named graph NG1 and the RDF dataset D2 with default graph DG2 and any named graph NG2)...
> ]]
>
> Does that work?

Yes.

>> * 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.
>
>
> Fixed.  Thanks.  There is a lot of markup in that section of the source :)

Ok.

>> * 5.4: "Semantic conditions of RDF MAY recognize other datatype IRIs...". The term "semantic condition" 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.
>
>
> I have changed that to a note and changed MAY to "might choose to" in order to avoid RFC 2119 language.

A note is fine by me.

> Can you please let us know as quickly as possible whether these changes are sufficient for you?

To summarize, I have agreed with all changes.

The WG may still consider to differently treat the "entity" issue above 
by simply replacing the occurrences of the term in the RDF Semantics 
(it's just a handful of such occurrences), but I leave this decision to 
the WG.

> Thank you again.
>
> Regards,
> Dave

Best regards,
Michael

> --
> http://about.me/david_wood
>
> [1] http://www.w3.org/2011/rdf-wg/track/issues/161
>
>
>>
>> Best regards,
>> Michael Schneider
>>
>>
>
Received on Monday, 21 October 2013 21:36:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 21 October 2013 21:36:22 UTC