checked RDF semantics for XSD stuff, couldn't grok namespace entailment

I noticed some places in earlier drafts
of the semantics doc that should cite various
XML schema specs. Since I've been dubbed
"voice of the XMLSchema WG"[11Dec], I'm
reviewing it today...

http://www.coginst.uwf.edu/~phayes/RDF_Semantics_finalCall_1.html
Fri, 13 Dec 2002 21:02:40 GMT

[11Dec]
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Dec/0165.html

In sum, the lack of citations has since been
fixed (though I did run across a broken
internal link, which see below).

Some stuff I noticed along the way...
hmm... is any of it critical? Well,
I think the bit about semantic extension
is CRITICALly unclear; I can't tell
if it's coherent or not because I can't
follow the pointers within the document.

Comments in document order...
most of these are editorial...
I'll mark the ones that I think could
be observed objectively (i.e. thru testing)
as WRONG.


| 0.1 Specifying a formal semantics: scope and limitations

| that model theory might be better called 'interpretation theory'

why is it not, then? [answer: cuz that's not
what logicians call it. Maybe cite tarski
or whatever the seminal work is, informatively?]

| The restriction to a mononotic logic is a
| deliberate design decision, however. 

is that design decision motivated in the concepts
doc? (see my earlier message about scalability)
If so, perhaps a cross-reference?
Of not, bummer.

| and OWL [OWL, 

missing ]

| language of RFC 2119

citation/pointer/href?

| All such extensions MUST conform to the semantic
| conditions in this document. 

Hmm... not clear what conforms(semExt, thisDoc)
means. CRITICAL.


| Any entailment which is valid according to the
| semantics described here MUST continue to be valid in
| any extended semantics imposed on an RDF namespace.

What's an RDF namespace? The term 'namespace' is
actually not defined (at least, not to my satisfaction)
in the XML Namespaces spec. Only the term 'namespace name'
is. Maybe I didn't read enough of the document;
but whatever I should have read should be forward-
referenced.


| as introduced in section 3 below.

no link?

I can't find any occurence of 'namespace entailment'
in section 3. CRITICAL.


| In the interests of brevity, we use the imaginary URI
| scheme 'ex:' to provide illustrative examples. To obtain
| a more realistic view of the normal appearance of the
| N-triples syntax, the reader should imagine this replaced
| with something like
'http://www.example.org/rdf/mt/artificial-example/'.

That's really wierd. Why make up an imaginary URI scheme?
Instead of <ex:a>, why not write ex:a and pretend
ex: is a namespace prefix, just like rdf: and rdfs:?

If ex: is really an imaginary URI scheme, then why
replace it by 'http:...'?

Well, after reading the rest, I see you do use
ex: consistently as an imaginary URI scheme.
Very well, then.


| arcs are of course never merged.

Why not? Merging
{ <ex:a> <ex:b> <ex:c> } with
{ <ex:a> <ex:b> <ex:c> } gives
{ <ex:a> <ex:b> <ex:c> }, no?

WRONG.


| A name is a uriref or a typed literal.

why not untyped literals? Oh... "We do not think of
plain literals as names because their interpretation
is fixed by the RDF semantic rules." Very well. thanks.

| An instance of an RDF graph is, intuitively, a
| similar graph in which some blank nodes may have
| been replaced by urirefs or literals.

At the risk of confusing natural language intuitions
with formal specification, that would be a lot more
clearly intuitive with an example ala:

	An instance of "Some page was written
	by Bob" is "Page47 was written by Bob."


| The use of the explicit extension mapping also makes it
| possible for two properties to have exactly the same values,
| or two classes to contain the same instances, and still
| be considered distinct.

strike 'considered'.

| It assumes, implicitly, that urirefs have the same
| meaning whenever they occur.

I think that overstates the case; the semantics only
assumes that each interpretation gives one denotation
to each uriref; interpretations corresponding to different
times might give different denotations to the same uriref.

WRONG.

(this would need a different sort of test than
the ones in our test document, but I think it
could be observed objectively.)

| We do not make any assumptions about the relationship
| between the denotation of a uriref and a document or
| network resource which can be obtained by using that uriref
| in an HTTP transfer protocol.

Again, that overstates the case. 'We' the formal semantics
editor don't make any such assumption. But we the RDF
Core WG do expect that URIs will usually be used in RDF
consistently with their use in HTTP, HTML and other conventional
contexts. This is what the intro to the semantics says;
directly only briefly, but indirectly thru the concepts
doc more elaborately.

| It has been argued that urirefs in the form of HTTP URIs
| should be required to denote the document that results from
| such a retrieval.

I don't know why you point out that misconception;
the more architecturally consistent view is that
it denotes a thing that, when sent GET messages,
sends you back a document.

| 1.3 Interpretations

I'm skipping ahead at this point...



| 3.4 Datatyped interpretations

| A datatype is identified by a uriref and is characterized
| by a set of character strings called lexical forms
| and a mapping from that set to a set of values.

'identified by a uriref' is superfluous, right?
Datatypes are no more nor less identified by uriref
than are web pages, pigs, numbers, or fairies, right?


broken link/anchor?
http://www.coginst.uwf.edu/~phayes/RDF_Semantics_finalCall_1.html#ref-xml-schema2


| we will refer to particular aspects of these conditions
| as different kinds of information about a datatype.

ugh... do we really need to?

no, after reading more, I don't see where
you actually do what you say you will here.

| where D is supposed to characterize information about some
| set of datatypes

ugh... why don't you/we just say

	where D is a set of datatypes

?

You later write things like ICEXT(I(rdfs:Datatype)) = D
which seem to say that D is a set of datatypes.


| any uriref beginning http://www.w3.org/2001/XMLSchema#sss

awkward/redundant; either say
	any uriref of the form ...#sss
or
	any uriref beginning ...#

| ICEXT(I(rdfs:Datatype)) = D

hmm... isn't that more constraining than it needs to be?
we only need ICEXT(I(rdfs:Datatype)) to include D, right?

WRONG. (I think).


| a datatype violation MAY be treated as a error condition.

seems superfluous. An error condition in
what context/process/protocol?

Just giving it the name 'datatype violation' seems
sufficient. (is that term anchored?
hmm... it's not in the glossary. I guess
the glossary is only for terms imported
from conventional literature, not for novel
terms in this spec. hmm... I hate having
to view-source to find anchor names; it would
be nice to have the terms introduced in this
spec collected somewhere.)

| a graph which contains a literal with a non-well-formed
| XML string or an illegal language tag, and which is typed
| with rdf:XMLLiteral is always considered a datatype violation.

eek... there are no RDF graphs with non-well-formed XMLLiteral
thingies, are there? i.e. the things in the graph
are post-xml-parsing, no? Ah... no, I guess they're
pre-parsing strings. OK. very well.

| Similarly, RDF does not assume that its literal strings
| are identical to elements of the class xsd:string, even
| though both are defined as sequences of unicode characters. 

Now that confuses me... if you're saying that RDF
doesn't include a specification of what the elements
of the class xsd:string are, and therefore it
doesn't specify that literal strings are in that class,
then very well. But surely in the case of D-interpretations,
i.e. where the class xsd:string *is* specified,
RDF's literal strings are in that class, no?

WRONG.

Jan/Jeremy, please add this test case:

	(empty graph)
	XSD-entails
	"abc" rdf:type xsd:string.



| Although the definition of entailment means that a D-inconsistent
| graph D-entails any RDF graph, it will usually be inappropriate
| to consider such entailments as useful consquences since they
| would not be valid rdf- or rdfs- entailments.

Really? Oh... had to read that 5 times before I got it.
OK.

| A datatype clash may be considered to be a datatype
| error condition.

I don't think that adds anything. I suggest striking it.

| It makes no provision for assigning a datatype to the range
| of a property, for example

???? what about
	my:age rdfs:range xsd:integer.
???

WRONG.

| and does not provide any way of explicitly asserting that
| a blank node denotes a particular value under a datatype
| mapping.

/me sighs

I sure wish we had specified that

  _:fourtyTwo xsd:integer "42".

works. Bummer. Rats. Frap.

| We expect that semantic extensions and future versions
| of RDF will impose more elaborate datatyping conditions.

Ah; good.

(that sort of side-note is traditionally
marked up with some NOTE: thingy. Hmm... the
tradition hasn't been codified in
http://www.w3.org/2001/06/manual/ )


| A graph rdf-entails (rdfs-entails) another just when its
| rdf-closure (rdfs-closure) simply entails it.

ooh! nifty... will that work for universal quantification
too? Ah... no...

| It is not possible to provide such a tight result
| for D-entailment closures since the relevant semantic
| conditions require identities which cannot be stated in RDF.


OK, I read carefully up thru...

| 4.1 Rdf-entailment and rdf closures (Informative)

That's it, for now, at least.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 13 December 2002 18:41:25 UTC