- From: Manos Batsis <m.batsis@bsnet.gr>
- Date: Fri, 19 Oct 2001 15:18:13 +0300
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, <tpassin@home.com>
- Cc: <www-rdf-interest@w3.org>
> -----Original Message----- > From: Peter F. Patel-Schneider [mailto:pfps@research.bell-labs.com] > From: Patrick.Stickler@nokia.com > Subject: RE: RDFCore Update > Date: Fri, 19 Oct 2001 13:35:23 +0300 > > > > > It is also important to note that, unless RDF itself defines > > a single, standard mechanism for data type validation, it can > > do nothing more than ensure that statements about data types > > do not conflict. Furthermore, same properties may use different datatypes over different but collaborative environments. So, I guess the best practice is to build and use a subclass of that property and then define it's datatype? From: "Thomas B. Passin" <tpassin@home.com> Subject: Re: RDFCore Update Date: Thu, 18 Oct 2001 23:52:44 -0400 > [Peter F. Patel-Schneider] > > > > > I don't know how you could handle a prescriptive meaning for rdfs:range in > > an open environment. You certainly can't say that the target object has > to > > belong to the range when the triple is read because there is no notion of > > order in RDF. > > But that only means that you cannot validate the graph until the whole thing > is constructed. That's no different that for XML Schema itself. Why do you > think that would be unworkable? It would let you separate graph > construction and validation into separate processing layers, which should be > good not bad. My problem in making a solid RDF app comes exactly from this issue. I would love a platform that would dynamically build a subgraph G' from graph G, according to current app needs. In general, I think this "dynamic context" thingy is what is missing from RDF, to allow further adoption and development (I guess that's why we still don't have a usable RDFPath language). Just passing by, Manos
Received on Friday, 19 October 2001 08:16:47 UTC