W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2002

RE: The latest proposal ++--

From: <Patrick.Stickler@nokia.com>
Date: Mon, 12 Aug 2002 10:28:00 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B160B95@trebe006.NOE.Nokia.com>
To: <Jan.Grant@bristol.ac.uk>
Cc: <w3c-rdfcore-wg@w3.org>

> -----Original Message-----
> From: ext Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> Sent: 10 August, 2002 12:33
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg
> Subject: Re: The latest proposal ++--
> On Fri, 9 Aug 2002 Patrick.Stickler@nokia.com wrote:
> > Delete it at will...
> >    expected/required datatype of datatyped literal nodes.
> >
> >    The following closure rule is defined:
> >
> >    IF
> >       ?s ?p "LLL" .
> >       ?p rdfs:range ?d .
> >       ?d rdf:type rdfs:Datatype .
> >    THEN
> >       ?s ?p ?d"LLL" .
> >
> >    This equates the global/implicit and local/explicit datatyping
> >    mechanisms.
> That's an interesting idea. Like I said, in my experience I 
> was able to
> use multiple schemas and still do "syntactic" long-range 
> typing, 

Well, if you put everything in a single, monolithic RDF/XML
instance, then you can handle lots of stuff syntactically,
but one of the nicest (IMO) features of RDF is that you
don't have to worry about the partitioning of the RDF/XML
mucking up the integrity of the knowledge base, but can
syndicate large numbers of RDF/XML instances into the same
graph and then work with the graph, completely ignoring
how the knowledge got there.

The particular partitioning used for the RDF/XML instances
can have authoring/management motivations that have nothing
whatsoever to do with the use of that knowledge by RDF
applications operating on the graph.

Having to do "long range" global typing syntactically would
be completely in opposition to this characteristic of RDF.

It's like saying that if you want to define rdfs:range
and rdfs:domain, you have to do so in the same RDF/XML
instance that the resources are mentioned -- i.e. syntactically.

I don't think so...

> but I'm
> semi-persuaded that global implicit might be useful. You (Pat) say
> you've got examples where it is necessary: could you extract the
> corporate secrets and present an example of what's left?
> I'd go for this, with the proviso that I haven't thought much 
> about it.
> Are there monotonicity problems? We certainly seem now to be able to
> produce inconsistent graphs (which I don't have a problem with)...
> 	<s> <p> "LLL" .
> 	<p> rdfs:range <xsi:integer>
> 	<p> rdfs:range <xsi:date>
> 	(plus datatype declarations, although I'm not totally convinced
> 	they're necessary)
> Now, that would appear to be inconsistent. 

No, though it is a contradiction. It's no different than

   <p> rdfs:range foo:/gender/Male .
   <p> rdfs:range foo:/gender/Female .

You can contradict yourself in many ways in RDF. And it
may be that the two conflicting range constraints come
from two completely different sources/authorities and
represent a disagreement about the world of discourse.

So? That's life in the Semantic Web...

> However I was under the
> impression that one of the things you wanted from long-range 
> typing was
> type intersection, which doesn't appear possible. Are you 
> prepared to do
> without it, or is there something I've missed?

Multiple ranges do constitute an intersection of types,
insofar as the assertions are concerned, but that doesn't
mean that those intersections can not contain conflicts.

I would expect that the same mechanisms that would be
provided by OWL to declar foo:gender/Male and foo:gender/Female
to be disjunct would also be used to declare that xsd:integer
and xsd:date are also disjunct. I.e., datatype classes are
just like any other RDF classes, except for the added 
characteristic of their lexical space and lexical to value
mapping; and all of the RDF machinery for dealing with
RDF classes also should work just fine with datatype classes.

Received on Monday, 12 August 2002 03:28:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:59 UTC