Re: RDF and (a subsets of) F-Logic

Jos de Bruijn wrote:

>> BTW in our own applications we do make use of what you call
>> "higher-order" features (especially in queries and in rules) and make
>> some use of "non-classical" (though those latter uses can often be
>> addressed by some sort of layered approach).
> What you mean with "non-classical" in this context? Do you mean things
> like nonmonotonic negation?

No, I was just referring to the terminology in your paper, where you 
define a "classical RDF graph" as one with DL-style disjointness between 
URI sets. Same with higher-order, I was referring to your definition. I 
had just been thinking about whether in our own usage we could limit 
ourselves to the restrictions needed for any of your later embeddings.

I thought we could meet "no nonstandard use of RDFS" but your answer 
below suggests we can't meet that one either.

>> In section 5 is there a reason that your "RDF interaction axioms" are
>> one way?  If one were trying to use this embedding as a way to perform
>> inference over RDF then you'd want the reverse direction as well.
> There are slight differences in the semantics of the subclass constructs
> in F-Logic and the RDF subclass constructs. In F-Logic, every individual
> is a subclass of itself, whereas in RDF, only individuals of type
> rdfs:Class are subclass of themselves.

Humm, OK.

>>   - in Definition 2 I suspect you mean ".. or
>> ContainerMembershipProperty, Resource, Class or Property occurs in *a
>> non-class position in* S."]
> Actually, no. 

So you define the notion of "class position" but don't use it anywhere, 
is that right?

> When considering such direct embeddings of extensional
> RDFS, we specifically want to avoid situations where some identifier can
> be made a subclass of ContainerMembershipProperty, Resource, Class or
> Property, or one of these identifiers can be made a subclass of some
> other identifier; this would change the semantics of the language
> constructs; in that case the direct embedding would no longer work,
> because it hard-wires the semantics of some of the RDFS language constructs.

You are going rather further than that, you are banning all use of 
Class, Property etc. That means one can't even declare a class or 
property within your definition of "standard RDFS use". I suggest 
renaming "standard" to "restricted" :-)

> I think it would have been possible to allow them as the object of an
> rdf:type triple (this would need to be verified).

That would be better, it would at least allow one to declare classes and 
properties.

Cheers,
Dave
-- 
Hewlett-Packard Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 26 March 2007 11:13:26 UTC