RE: datatypes and MT

> > But only if you really mean that each literal above
> > is a separate, unique node and that node has context
> > within a specific statement. I.e.
> >
> > _1:"10" rdf:type xsd:decimal.
> > _2:"10" rdf:type xsd:string.
> > _3:"10" rdf:type xsd:float.
> > _4:"10" rdf:type xsd:double.
> > _5:"10" rdf:type xsd:gYear.
> > _6:"10" rdf:type xsd:gMonth.
> > _7:"10" rdf:type xsd:gDay.
> > _8:"10" rdf:type xsd:hexBinary.
> 
> I wrote (but you cutted that)
> 
> ...are making sense, also taken *together*
> and their subjects are different nodes
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My sincerest apologies, I missed that. I guess that's
the problem with all these disparate notations, it's
hard to know how literally to interpret them and
what they are really denoting. 

And of course, I need to read a bit more carefully ;-)

> and I don't think one needs extra node labeling
> (because one can talk about such *nodes*, be it in
> the EC subset of Notation3)

Now you've lost me.

How do you know *which* literal node is meant if
their only identity in the triples is the literal
itself (node label) which is ambiguous?
 
> > I.e. it is the node, not the literal, that is
> > the subject of the above statements.
> 
> sure, the subject is a node written "10"

But triples do not preserve context of literal
objects without explicit nodeIDs specified both
for object and the subjects of any statements
made about the object.

If you want to draw a graph

  X ---someProperty---> "10" ---rdf:type----> xsd:integer

and not include the nodeID, fine, but if you
distill that graph to triples, you have to use the nodeIDs

  X someProperty _:1:"10" .
  _:1 rdf:type xsd:integer .

you can't just write the triples as

   X someProperty "10" .
   "10" rdf:type xsd:integer .

or else you lose the context of the statement in which the
literal node acts as object.

> > >   "10" rdf:type xsd:decimal; is eg:shoeSize of eg:me.
> > >
> > > to say something about a *particular* node
> > > (because the ';' repeats that particular subject)
> > > or something like
> > >
> > >   eg:me eg:shoeSize "10", [ rdf:type xsd:decimal ].
> >
> > Do you rather mean
> >
> >    eg:me eg:shoeSize [ rdf:value "10", rdf:type xsd:decimal ].
> 
> as Pat argued, it would be better to write that as
> 
>   eg:me eg:shoeSize [ = "10", rdf:type xsd:decimal ].

With all due respect, Yuck! ;-)

This is what I meant earlier about our seemingly going in
circles about notation issues and failing to focus on what
the actual model is.

It really doesn't matter so much *how* we represent the model
in the notation as much as what the model is we are really 
trying to represent.

This is why I pushed down a level to an abstraction based
on statements, that can then have various interpretive
views, and the notations can themselves reflect those views.

Thus, one can use the X notation to define the underlying
canonical model, or e.g. a modified NTriples or RDF/XML
notation to make statements in a resource-centric manner.

The reason why questions such as is "10" in your NTriples
example a unique bNode with a label of "10" or the actual
literal "10" which constitutes global intersection...

If we would first define our underlying model, and then worry
later about higher level views and notations based on those
views, I think we'd all be happier (I know I would ;-)

Thus, insofar as I've understood you, your example above
would be expressed in the X model as

  [1,U,X]
  [2,U,someProperty]
  [3,L,10]
  [4,S,1,2,3]
  [5,U,rdf:type]
  [6,U,xsd:integer]
  [7,S,3,5,6]

which, based on a resource-centric view, corresponds
to the graph interpretation

  X ---someProperty---> "10" ---rdf:type----> xsd:integer

Eh?

> > or
> >
> >    eg:me eg:shoeSize _1:"10" .
> >    _1:"10" rdf:type xsd:decimal .
> 
> no, I meant what I wrote
> 
>   eg:me eg:shoeSize "10", [ rdf:type xsd:decimal ].
> 
> or
> 
>   eg:me eg:shoeSize "10".
>   eg:me eg:shoeSize [ rdf:type xsd:decimal ].
> 
> which would require the assertion
> 
>   eg:shoeSize rdf:type daml:UniqueProperty.
> 
> to conclude that both object nodes "10"
> and [ rdf:type xsd:decimal ] are the same thing
> (but again you cutted that piece of text)

Huh? so now every property in the graph gets *two* value
nodes, great... (need to buy more memory ;-)


> > > Another assumption is that
> > > 
http://www.coginst.uwf.edu/users/phayes/w3-rdf-mt-current-draft.html
> > is not excluding literals in the rules for RDFS entailment e.g.
> >
> >   rdfs3
> >   xxx aaa uuu . aaa rdfs:range zzz . |- uuu rdf:type zzz .
> >           ^^^yyy                        ^^^yyy
>
> > If you mean that rdfs:subClassOf relations between data types
> > defines a relation between lexical spaces, then I disagree.

> not lexical of course not

But how does "not excluding literals" = "not lexical"?

Patrick

Received on Wednesday, 14 November 2001 10:06:56 UTC