comments on Semantics

Here are my comments on Semantics.  Some of this I guess I'll fix up as editor.  Some I may need help on.  Some Pat and I will iron out, hopefully.  The main sticking point I see is the statements about blank nodes.

There was some discussion of how normative is supposed to work now.  Does anyone have a pointer to the rules?


Comments on RDF 1.1 Semantics

1/ Need to fix up printing
  - too big
  - notes don't show up right
probably copy stuff from Concepts

2/ Need to say what is normative?

I believe it is 1 (!), 2, 3, 4 (except summary), 5, 6 (?), 7, 8, 9, 10, 11,
12 (except 12.1), 13.  14 is not normative (and should be removed, see below).

2/ Need to copy the "key words" boilerplate from Concepts Section 2.

1, after first paragraph, copy boilerplater from Concepts

3/ Fix terminology from Concepts

3, first paragraph
- add IRI
- remove RDF source?

4/ Need to say what the syntax means better

3, last paragraph
Throughout this document RDF graphs and other pieces of the RDF abstract
syntax are written using Turtle syntax [Turtle-TR].  The namespace prefixes
rdf:, rdfs:, and xsd: are as in RDF 1.1 Concepts, Section 1.4.  When the exact IRI
doesn't matter, the prefix ex: will be used.   When ....  Angle ....

5/ More care about blank nodes

4.1, first paragraph
conventional logical notion, with only a local meaning.

5, on union

This isn't right.  A subgraph of an RDF graph shares blank nodes with the
graph it comes from.  Treating it as a separate graph is some weird
operation that comes from nowhere.  To make this point correctly would
require saying that there is an RDF graph available from a source.  If
pieces of it are transmitted across the web using current RDF syntaxes and
turned back into RDF graphs then these two graphs do not share blank nodes
and ....

The section on merging should read

The process of combining ....  Merging is typically achieved by changing
blank node identifiers ... blank node identifier.

6/ Separate normative and non-normative

New normative section in 4, 4.3 Semantic Extensions with only last paragraph
of 4.2

7/ Remove value judgements

Opions vary .... -> 

8/ Be more careful about namespaces and vocabularies

10. and several IRIs with the namespace prefix rdf:
10. normative meanings on other IRIs with the namespace prefix rdf:

9/ Fix claim about rdfs:Datatype

I don't see anything that prevents other members of rdfs:Datatype.  I think
that OWL actually uses this.

11. the class rdfs:Datatype contains all the references of recognized
datatype IRIs.

10/ Better example for rdfs:Literal (because numbers might not be recognized)

12.1  "24"^^xsd:string .... string "24".

11/ Remove 14

It is not the case that distinct RDF graphs can't share blank nodes.
Applications can do whatever they please.   Someone could even write a
surface syntax for RDF so that applications could send representations of
blank nodes back and forth.  This would be stupid, but it wouldn't violate
anything in RDF.

Concepts makes most of the points about the referent of graph names.

12/ Fix B

I think that you need more domain elements than required in this section.

13/ rdf:value

How can rdf:value be used for a property that has several values?  First of
all, properties (as properties) don't have values.

14/ References

RDF Concepts really has to be normative.
RDF PlainLiteral has to be normative.
Turtle has to be normative (so that the syntax has a normed meaning).

XML 10 doesn't have to be normative, as it is only used in explanation.  The
normative meaning goes through Concepts (and then XML Schema).

RDF Schema doesn't have to be normative, as it only describes what is
defined in Semantics.

RDF Primer can't be normative as it doesn't have any normative content.

SPARQL Query doesn't have to be normative (if it is even referenced).

XML Schema doesn't have to be normative as everything goes through Concepts.

Wording changes:

2. impose user-define -> be given
3. Remove Issue 1 (except that Concepts may pick up a definition of merge)
3. identifiers may have to be changed in order to
7. with rdf:langString as their type
7. Such literals SHOULD be
9. {}-entailment (to prevent bad line break)
9. similar literal -> another literal
9. similar triple -> another triple
10. Some consequences of the RDF semantic conditions ...
11. , and so are RDF entailed
B. truthvalues -> truth values

Received on Wednesday, 22 May 2013 05:42:50 UTC