- 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