Comments on the new RDF Model Theory spec [editoral part]

**** EDITORIAL PART
**** After
**** http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0093.html


> ><quote>
> >There are well-formed graphs that cannot be described by these 
> >notations, however.)
> ></quote>
> >EDITORIAL:
> >What does "well-formed" means? That's a big problem thorough all the 
> >draft, too many times terms are
> >used without proper definitions (or, a term is used before being 
> >defined, without reference).
> 
> Sigh. I guess I never know quite how far I have to go in order to 
> explain terms that seem to me to simply be part of the language. If 
> it bothers you, I could just omit the phrase "well-formed".

Yes please (one beer :)


> ><quote>
> >Blank (unlabeled) nodes are considered to be drawn from some set of 
> >'anonymous' entities which have no label and are unique to the graph
> ></quote>
> >EDITORIAL:
> >What's a "label"...?!
> 
> Formally, this is meaningless. Intuitively, it is intended to convey 
> the intuition that blank nodes are indeed blank; they have no name.

Yes, but it is still meaningless.... I know it's a challenge to be clear
and also not to use new terms, but.... can we try? (won't dare to 
offer other beers for each of these :)


> ><quote>
> >Other RDF serializations may use other means of indicating the graph 
> >structure; for our purposes, the important syntactic property of RDF 
> >graphs is that each distinct item in an RDF graph is treated as a 
> >distinct referring entity in the graph syntax.
> ></quote>
> >EDITORIAL:
> >What does this formally means? First, "serialization" is not 
> >defined. Second, the rest of the paragraph makes
> >little sense.
> 
> Well, I disagree. I think it makes perfect sense. Can you articulate 
> in what way it fails to convey the point?

I'm confused by the wording "item in an RDF graph" here. What is it?

> >If we need to talk about serializations, let's give a definition and 
> >state their prpoerties.
> >Likely, we don't need this here, but if you feel we do, then let's 
> >do it right and clearly.
> 
> We cannot define every word we use. The concept of a serialization is 
> surely familiar to most readers of the RDF documentation. The 
> sentence is intended only to be helpful, not to be a formal 
> definition.
But yet, it's never defined in all the collection of RDF documents...
ISSUE:
So, yes, MT might not be the right place, but if "RDF serialization"
is used, somewhere it has to be defined....


> ><quote>
> >This might seem to violate one of the axioms of standard 
> >(Zermelo-Fraenkel) set theory, the axiom of foundation, which 
> >forbids infinitely descending chains of membership
> ></quote>
> >EDITORIAL:
> >Think about some poor guy who's reading this and doesn't have a 
> math degree
> 
> Then he should skip the technical sections. In any case, speaking as 
> a poor guy WITH a math degree who has been forced to read the XML 
> documentation and such horrors as RFC 2396, I don't have much 
> sympathy.
I sympathize, but then, does RDF Core wants to be as bad...? ;)
Seriously, some references are really in order here.

> >... This is all stated without references,
> >so some literature pointers should be added (if you can't avoid 
> >mention it, then at least give people hooks ;)
> 
> I really cannot be expected to provide an entire background course in 
> formal set theory. If you give "Zermelo-Fraenkel set theory" to 
> Google you should get something readable.

Again, references are in order here: sorry, it's the painful job of
the editor! ;)


> >(and it is used all along
> >after this), while before in the doc, there's always been "blank 
> >nodes". Consistency would be better.
> 
> If you prefer. We have used both terms so much in other documents 
> that it seemed best to use both of them here as well.

A second beer...? :)


> ><quote>
> >Notice also that the unlabeled nodes themselves are perfectly 
> >well-defined entities with a robust notion of identity
> ></quote>
> >EDITORIAL:
> >"robust" notion of identity....?
> 
> Yes, robust. Clear, unambiguous, not open to doubt or shilly-shallying.

Still, even taking out "robust", what does this mean?


> >EDITORIAL:
> >Why use KIF syntax rather than well-known (and much more common) 
> >first order logic formalisms?
> >In any case, at least, some explanation of the syntax should be given.
> 
> If you need one, we give a reference. I would have thought it was 
> pretty obvious. In any case, KIF is well-known and widely used, and 
> KIF syntax *is* a first-order syntax. There is no single canonical 
> first-order syntax: one can find prefix, postfix, infix, and 
> graph-based syntaxes in the logical literature since Frege (1898)

Yes but among 100 people who will read the spec, how many will
have used KIF or Frege's? A (non-normative) reference is at least in order.
Alternatively, why don't writing simply thing like 
"There exists an y such that ( ex:a(y,ex:b)  and  ex:b(ex:c, y) ) " ?
It's readable by everyone, and even if not formalized (strictly 
syntactically speaking), the whole purpose of this is not to be
normative but explicative (the clearer, the better).
The KIF syntax could then be used as well, as formal companion.


> >once noted finite-domain reasoning can be applied.
> 
> Why finite-domain reasoning?? IR isn't required to be finite.

And that's why I say "noted" (you've to observe that no matter
apparent infinite sets hanging around, the model checking
can be brought to finitary). But anyway, no big deal.


> >EDITORIAL:
> >Do we really need this complex subsection in the main spec, and not 
> >just as an appendix?
> >It doesn't seem to give any mainstream contribution (even, it has to 
> >introduce yac (yet
> >another concept), lean graphs, just to prove the lemmas, which 
> are accessory.
> >So, the added value in the normative main text is probably not worth 
> >the complexity this adds
> >to the reading.
> 
> Possibly. I could put all this into the appendix and just have a few 
> examples and remarks in the main text.

Yes, please. If I'm on 2 at the beer count, this is definitely worth
a third one for readability (even a fourth, but I'll not say it ;)

Thanks,
-M

Received on Wednesday, 22 May 2002 12:21:03 UTC