- From: Dan Connolly <connolly@w3.org>
- Date: 02 Aug 2002 08:47:04 -0500
- To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Cc: w3c-rdfcore-wg@w3.org
On Fri, 2002-08-02 at 05:17, Graham Klyne wrote:
> At 01:58 AM 8/2/02 -0500, Dan Connolly wrote:
> >---
> >:rangeSyntax a r:Property;
> > s:range :Datatype.
> >
> >@prefix log: <http://www.w3.org/2000/10/swap/log#> .
> >
> >this log:forAll :P, :L, :DT.
> >
> >{ [] :P :L.
> > :P :rangeSyntax :DT.
> >} log:implies { [] :DT :L }.
> >
> >:rangeSyntax s:comment { # example...
> > { ex:age :rangeSyntax dt:integer.
> > ex:jenny ex:age "10" }
> > log:implies { [] dt:integer "10" } }.
> >---
>
> Maybe I'm missing something here,
I confused you with the use of [] in the premise
and the conclusion; they're not the same variable.
> but what if there are two such properties?:
>
> [] :P1 :L1 ;
> :P2 :L2 .
> :P1 :rangeSyntax :DT1 .
> :P2 :rangeSyntax :DT2 .
>
> then doesn't that also give us:
>
> [] :DT1 :L1 ;
> :DT2 :L2 .
no, it gives
[] :DT1 :L1.
[] :DT1 :L2.
Each [] is a different existentially quantified variable.
Perhaps the rules is more clearly written:
{ :S :P :L.
:P :rangeSyntax :DT.
} log:implies { _:something :DT :L. this log:forSome _:something }.
> ?
>
> I'm thinking there may be problems with things like:
>
> :Jenny :age "10" ;
> :weight "70" .
>
> leading to something like this:
>
> :Jenny :integer "10" ;
> :integer "70" .
no, it just gives
_:x :integer "10".
_:y :integer "70".
> >So I'm starting to wonder if it makes more sense
> >to specify datatypes in terms of some of the WebOnt
> >features... or move some WebOnt features
> >into RDFS or something...
>
> Hmmm... that has a ring of sense to it. I read that as suggesting a full
> account of datatypes really belongs at a higher layer. I still think
> there's a case for a strictly local handling of datatypes in RDF, as in:
>
> :Jenny :age _:x .
> _:x :integer "10" .
>
> but I think that doesn't depend on anything in RDF that isn't already
> there, other than a convention for naming XML schema datatypes with URIs,
> and interpreting them as RDF properties.
But are there *any* consequences to this convention?
> I can also see merit in Guha's suggestion, which I see as effectively being
> a way to distinguish literal datatypes syntactically and extending the
> domain of graph literals to include non-strings. I think that's similar to
> what others have asked for, to parallel what happens in most programming
> languages.
Yeah... functional terms, even a limited f(l) form, where
f is a URIref and l it a literal, are appealing.
> As a long-time proponent, I agree that global datatyping can be very useful
> -- but I'm just not convinced we collectively know enough to do it properly
> at this time.
>
> The tough question, I think, is whether we need to commit to tidy literals
> throughout at this time,
I find that question easy to answer, in the affirmative.
> or is there a way to leave an escape hatch for
> future developments? For example (adapting Guha's suggestion, and
> reverting to XML):
>
> <rdf:Description about="http://example.org/Jenny">
> <ex:age>10</ex:age>
> </rdf:Description>
>
> would not actually specify anything semantically beyond
>
> < I(http://example.org/Jenny), x > in IEXT(I(ex:age)), for some x
>
> but something like:
>
> <rdf:Description about="http://example.org/Jenny">
> <ex:age xsi:type="xsd:string">10</ex:age>
> </rdf:Description>
>
> or
>
> <rdf:Description about="http://example.org/Jenny">
> <ex:age xsi:type="xsd:decimal">10</ex:age>
> </rdf:Description>
>
> would force the tidy interpretation that you use in your work.
This sort of design is only interesting to me if xsi:type
defaults to string.
> There are still questions about the form of the abstract graph (ack.
> Jeremy) -- I can imagine a couple of possibilities, but I don't think
> they're as hard to solve as what we've been trying to do.
>
> #g
>
>
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you in Montreal in August at Extreme Markup 2002?
Received on Friday, 2 August 2002 09:46:39 UTC