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

Dave Reynolds wrote:
> 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.
Note that the "no nonstandard use" is only necessary for a particular
embedding of extensional RDFS, which is not the normative semantics for
RDFS. For the embedding of standard RDFS, we do not require any
restrictions on the RDF graph.
>
>>> 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?
I guess so.
>
>> 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 don't think it is really that restricting.  Most of such typing
statements (as mentioned below) are redundant. Whenever any identifier
is used, it is of type Resource, whenever an identifier is used as a
property, it is of type Property, and whenever an identifier is used as
a class, it is of type Class.
>
>> 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.
I think it is possible to allow such triples in the entailing graph, but
not in the entailed graph. But this is something which would need to be
checked further.

Best, Jos
>
> Cheers,
> Dave

-- 
Jos de Bruijn,        http://www.debruijn.net/
+43 512 507 6475         jos.debruijn@deri.org
DERI                      http://www.deri.org/
----------------------------------------------
When we remember we are all mad, the mysteries 
disappear and life stands explained.
  - Mark Twain

Received on Monday, 26 March 2007 12:12:46 UTC