RE: The X Datatype Proposal

(Sorry this reply is delayed, I put off the long msgs until the 
shorter ones were dealt with. Hah!
-Pat)
.....
>
>>  >prescriptive range
>>  >
>>  >         A range constraint for a particular predicate
>>  defining a global
>>  >         type which all local types for all values must be
>>  equivalent to
>>  >         (either identical to, or a subclass of, the defined
>>  range class)
>>
>>  I see no difference here between prescriptive and descriptive. The
>>  former seems to be the same as the latter with the provisio added
>>  that everything must be consistent; but that is a vacuous condition
>>  in an assertional language.
>
>There is a *huge* difference. It's as significant as the difference
>between XML well formedness and XML validity.

I assume that we have now thrashed this point to death, right?

As I understand it, this distinction has no meaning in RDFS itself, 
though it may have for some systems that propose to use RDFS 
information to do type-checking.
....

>
>>  >node facet
>>  >
>>  >         A primitive property of a graph node serving as the
>>  >         label of an arc
>>
>>  ?? What about two different arcs coming out of a single node? I don't
>>  see any utility to this idea of a 'facet'.
>
>The reason for calling node properties "facets" is to distinguish
>them from RDF properties in general. Facets are primitives of the
>graph model, not RDF properties that are defined by RDF constructs
>or governed by RDFS property relations. You can't e.g. relate
>facets via rdfs:subPropertyOf.

Then I am completely confused. Above you say that the facet serves as 
the label of an arc. Labels on arcs in an RDF graph *are* the names 
of RDF properties. So what is this distinction that you are making 
here?
(Or are your graphs not RDF graphs at all? But then why are we even 
discussing them in this WG?)

>
>Facets are not members of the class rdfs:Property.
>
>There is no problem with a given node having multiple facets, but
>the specific facets for each type of graph node are fixed in the
>node model. You cannot define arbitrary facets from arbitrary
>ontologies. It is a bounded set defined by the model.
>
>The example implementations for Java and Relation Tables should
>make this quite clear.

Unfortunately not. It remains completely opaque to me.

>
>>  >LNode
>>  >
>>  >         A node representing a resource labeled by an RDF Literal
>>  >
>>  >UNode
>>  >
>>  >         A node representing a resource labeled by a URI Reference
>>  >
>>  >SNode
>>  >
>>  >         A node representing an RDF Statement
>>
>>  Interesting, I was not aware there were any such nodes.
>
>There are, in my proposed model.

?? What is this proposed model a model *of*, and what has it got to 
do with RDF(S) ?  In another message you agreed with my guess that it 
was a meta-description of RDF in RDF; but that isn't consistent with 
it having a primitive graph notion that is not part of RDF. So I am 
left helpless to understand what this proposal is even *about*.
......

>  > >Separation of a lexical form from either the lexical space or
>>  >value space for which it was originally expressed renders it
>>  >uninterpretable in a reliable manner.
>>
>>  That isn't obvious.
>
>OK, let me try (again) to make it obvious.
>
>If we have
>
>    _:X _:someSubProperty "12" .
>    _:someSubProperty rdfs:range foo:hexInt .
>    foo:hexInt rdfs:subClassOf xsd:integer .
>    _:someSubProperty rdfs:subPropertyOf _:someSuperProperty .
>    _:someSuperProperty rdfs:range xsd:integer .
>
>and we have a query
>
>    _:X _:someSuperProperty ?V .
>
>which binds ?V to "12", implying the statement
>
>    _:X _:someSuperProperty "12" .
>
>and then an application attempts to interpret the literal "12"
>in terms of the type defined for someSuperProperty by rdfs:range,
>namely xsd:integer, it will get the value 'twelve' but in fact,
>the value is actually 'eighteen' !!!

Right, that point is well taken. My point was only that there might 
be some coherent mechanism for assigning the correct interpretation, 
even though the information about datatyping is separated from the 
literal. What your examples show is that a naive use of class 
hierarchy reasoning to do this assumes some rather strict discipline 
in the datatype mappings, and indeed I am grateful to you for making 
that clear. It isn't obvious that a more sophisticated technique 
cannot possibly work, however.
.....

>
>>  >The basis for the graph representation, and all operations and
>>  >interpretations, should be the explicit reification of the
>>  >statement.
>>
>>  NO!!  I refuse to have anything to do with a proposal that requires
>>  global reification just to handle literals. It is unworkable,
>>  impossibly baroque, incompatible with all known uses of RDF
>>  (including DAML ) and with XML, and semantically confused.
>
>Eh? I think you're having a "knee jerk" reaction here...
>
>Are you telling me that one cannot derive the present resource-centric
>graph representation from this model?

I'm certainly telling you that I have no idea how to do so (or what 
'resource-centric' means, BTW); but more to the point, what anyone 
can or cannot 'derive' is irrelevant. If this suggestion is supposed 
to be a way of *implementing* RDF graphs, then I have nothing 
particularly to offer in the way of comment about it, other than it 
seems off-topic for this WG. If it is being proposed as an 
*alternative* to the current graph model, then it seems to me to be 
far too late in the process to consider such a far-reaching change in 
the basic RDF model, one that would require us to rewrite every 
single document and redefine the entire language from top to bottom. 
It is just way out of scope.

>Is not the foundation of the RDF conceptual model based on the
>statement?
>
>How is this model more baroque than the present graph model which
>requires *two* representations for each statement just to reify
>the statement, one that is resource centric and one that is
>statement centric?

Well, reification seems like a peripheral matter to me. There is a 
very good chance that reification will simply be tossed out as broken 
by the WG. Even if not, it is clearly not central to RDF, and I would 
be most unhappy if it were to be made central to it.

>And it doesn't require global reification in the sense of reification
>per the current graph model, which I agree would result in a grossly
>baroque and obese graph.

But your graphs (eg the one at the end of this message) are far more 
obese, not to say baroque, than the result of reifying an RDF graph 
using RDF reification. Later in this very message you expand a single 
triple into a graph with 11 nodes (4 of them bNodes) and 10 arcs; 
triple-bloat on an unprecedented scale, by an order of magnitude. The 
simple RDF reification would only have generated 2 new nodes and 4 
new arcs to give totals of 4 nodes and 5 arcs. Moreover, your 
expansion is *compulsory*; even if I don't give a damn about reifying 
anything, on your scheme my storage and bandwidth needs will expand 
by a factor of ten. (That is Nokia you work for, right, not 
Microsoft? ;-)

>And it's not just for handling typing of
>literals, the same model addresses that, but also the (IMO critical)
>issues of statement qualification (scope, source, authority, etc.)
>which I'm sure is of great interest to the community at large.
>
>And it is *NOT* incompatible with any existing RDF applications
>as it is trivial to provide a logical resource-centric interpretation
>of this model per the current graph model. I.e.
>
>
>                     application
>            ----------------------------
>                 resource-centric API
>            ----------------------------
>               statement-centric model
>
>Thus, it is not getting in between the current RDF model and
>current applications, but providing a foundation below the
>current resource-centric graph "view" that provides a better
>(IMMHO) basis for addressing the issues of data typing and
>statement qualification.
>
>Finally, from the perspective of a software engineer who has to
>make all this stuff work, it is *MUCH MORE* workable than the
>present model and provides the explicit mechanisms by which
>disparate applications can have a standardized and portable
>solution for interchange, query behavior, type integrity,
>and even shared, distributed knowledge bases.
>
>The resource-centric view of the present RDF model is useful
>for humans, surely, and we can continue to think in terms of
>that view, but a statement-centric model is IMO a much better
>foundation for RDF to address the many important issues that
>it is presently faced with.
>
>I hope that my examples for statement qualification and
>graph compression bear that out.

I confess to being quite unable to understand any of the above, or 
any of examples. Also I am not sure what you mean by 'statement 
qualification'.

>
>>  >An RDF graph should represent the statements which
>>  >constitute knowledge,
>>
>>  Quite.  Not statements that *describe* the statements that
>>  represent knowledge.
>
>The proposed graph model does not make statements, it represents
>statements.

?? But the graph already represents statements. (Why do you want to 
do it AGAIN?)

>An SNode is not a statement about an RDF Statement, it is
>the model of an RDF Statement.

What sense of 'model' are you using here?

>  > There is a well-known dodge referred to in Krep circles as 'escaping
>>  to the metalevel'. When things get awkward, just *describe the
>>  syntax* rather than trying to get the meaning straight.
>
>That's *not* what this proposal does. Sorry. Nope. Read it again.
>
>It simply inverts the explicit/implicit relation of the
>resource-centric view and statement-centric view. I.e.
>
>It does not add an additional meta-level not already defined by
>the RDF conceptual model for statement reification, it just adopts
>reified statements as the key representation of knowledge.

But that doesn't make sense. Reified statements do not encode 
knowledge of anything other than other statements. At some point you 
need to get down to brass tacks and actually start talking about the 
world. Where and how does this happen, in your scheme?
.....
>  >
>>  I rest my case.
>
>I don't see that you have a case. Not in terms of your
>comments here.

Sorry, I was being facetious. The graph you showed was so obviously 
much larger than the RDF graph that the contrast seemed to speak for 
itself.

>That first example was an abstraction,

What does that mean??

>and in fact is
>what is embodied in the resource-centric representation.
>And in fact is very similar to the knowledge embodied
>in your P++ proposal! E.g.
>
>  <urn:foo> urn:someProperty "bar" .
>
>implies
>
>  [ nodeID "1"; label <urn:foo> ]
>     [ nodeID "2"; label urn:someProperty ]
>        [ nodeID "3"; label "bar" ] .

No, it does not imply any such thing. It *is* a graph with two nodes 
and one arc, period. About the only thing it implies are a few 
similar triples involving bNodes, and it doesn't expand into 
anything.  NodeIDs occur in the Ntripes syntax, not in the graph.

>which expands in to essentially the same abstraction
>(apart from node types):

Now wait a minute. I certainly didn't propose this 'expansion', 
right? In fact I don't even know what this diagram is supposed to be. 
Previously I assumed it was an RDF graph drawn in an idiosyncratic 
way, but now  I think that was a mistake on my part. But what is it, 
then? Is it a diagram of some kind of datastructure?)

>
>       [ ]
>        |
>        ---- ID ----------> 1
>        |    
>        ---- subject -----> [ ]
>        |                    |
>        |                    ------ ID ------> 2
>        |                    |
>        |                    ------ label ---> <urn:foo>
>        |
>        ---- predicate ---> [ ]
>        |                    |
>        |                    ------ ID ------> 3
>        |                    |   
>        |                    ------ label ---> <urn:someProperty>
>        |
>        -----object ------> [ ]
>                             |
>                             ------ ID ------> 4
>                             |
>                             ------ label ---> "bar"
>
>Thus, we're really talking about comparable models,

My dear fellow, I honestly do not know what you are talking about, 
but I assure you that I am not talking about anything remotely like 
it. The graphs I am talking about do not have any numerals in them, 
and they do not have things called IDs or links named 'subject' or 
'label', and they do not have facets. Please do not attribute any of 
this to me.
.....

>Perhaps you can explain, in terms of the current graph model,
>how to address the many issues that I have identified. I've
>not yet seen any real solutions based on the current graph
>model. At least this proposal *provides* solutions.

I don't even know what issues you are referring to, I'm afraid.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Friday, 16 November 2001 18:20:21 UTC