Re: RDF in RIF

Dave,

Thanks for the comments.  Find some replies in-line.

>> I had an action (285) to propose a text for combining RDF with RIF core,
>> based on an axiomatization of the RDF semantics, embedding blank nodes
>> as Skolem constants.
> 
> Great start. Some embedded comments below.
> 
>> A question is which semantics of RDF (simple entailment, RDF entailment,
>> RDFS entailment, and extensional RDFS entailment) we want to be able to
>> use in RIF.  We will probably need a mechanism in the syntax to say
>> which kind of entailment is required.  In the remainder I will speak
>> about RDFS entailment, but this can easily be parameterized.
> 
> I don't think out basic embedding should include any entailment.

I assume you mean the basic embedding should cover only simple entailment?

> 
> We could have a non-normative set of predefined rulesets which capture
> appropriate RDFS entailment fragments that people can include/import
> (whatever our mechanism is) into their RDF rule sets if required.
> 
> Experience with Jena is that different people with different application
> needs want different fragments of RDFS. For example, some people want to
> see all the axiomatic triples, some don't.

We should have at least normative rule sets which correspond to the
kinds of RDF entailment defined in the specification.

If we want to define embeddings of fragments of RDFS, we should make
sure that these are well-defined.

> 
>> I propose the following text about interoperation between RDF and RIF:
>>
>> Interoperation between RIF and RDF is achieved by embedding RDF graphs
>> as sets of RIF facts, and by axiomatizing the semantics of RDFS
>> entailment using a set of RIF rules.
>>
>> == Embedding of symbols ==
>>
>> RDF defines four kinds of symbols:
>> - URIs
>> - blank nodes
>> - plain literals
>> - typed literals
>>
>> By the RDFS semantics, every symbol is interpreted as a resource.  RIF
>> defines the sort rif:iri, which corresponds to the set of RDFS
>> resources.  
> 
> Does it? I had thought rif:iri corresponded to URIs not to rdfs:resource.

The semantical domain of rif:iri is just some arbitrary set, as is
rdfs:Resource.  However, I just realized that rif:iri also restricts the
syntax.  Therefore, we should probably simply use the sort
rdfs:Resource, and make rif:iri a sub-sort.

> 
>> Hence, the embedding of every RDF symbol will be a member of
>> the sort rif:iri.
>>
>> [JB: we might as well use rdfs:Resource directly as a sort; this might
>> be a sub-sort of rif:iri, or rif:iri might be a sub-sort of
>> rdfs:Resource]
>>
>> We use a function tr_S which maps RDF symbols occurring in an RDF graph
>> S to RIF symbols.
>>
>> tr_S maps RDF URIs  to symbols of the sort rif:iri: tr_S(URI) =
>> "URI"^^rif:iri
>>
>> tr_S maps each blank node name x in the graph S to a new globally unique
>> constant symbol gensym(x,S) of the sort IRI: tr_S(x) =
>> "gensym(x,S)"^^rif:iri
> 
> I would like to have a marker for such skolem constants to facilitate
> round tripping. I guess this could be a constraint on the syntactic form
> of the iri's generated by gensym or a sort rif:bNode which is a sub-sort
> of rif:iri.

I guess that having a sort would be the most elegant solution.  However,
I am not entirely sure what kind of round-tripping would be required.

I think you have the scenario in mind that somebody syntactically
encodes the RDF graph as a set of RIF facts, and later wants to extract
the original RDF graph from the facts.

What I am thinking, is that we might not want to create yet another
syntax for RDF, but rather exchange the RDF graph using one of the
syntaxes proposed for RDF (e.g. RDF/XML).  In this case, the proposed
embedding would be used for combined processing of an RDF graph and a
set of RIF rules.

> 
>> For the embedding of plain literals in RIF we use the sort rdfs:Literal,
>> which is a sub-sort of rif:iri:
> 
> Sub-sort of rdfs:resource?
> 
>> [JB: another possible way to embed both plain and typed literals is by
>> using typing]
>>
>> tr_S maps plain literals "xxx" to symbols of the sort rdfs:Literal:
>> tr_S("xxx") = "xxx"^^rdfs:Literal
> 
> A plain literal without a lang tag is semantically equal to an
> xsd:string literal. So I think we should make that:
> 
>    tr_S("xxx") = "xxx"^^xsd:string

there are slight differences in the definition; rdfs:Literals seems to
allow more characters, but equality seems to be defined the same for
both.  However, we might want to retain the information which was in the
original graph (e.g. for certain kinds of queries).

> 
>> [JB: we need to discuss how to embed the language tag; this could be
>> done, for example, by declaring sub-sorts of rdfs:Literal for the
>> respective languages]
> 
> I think we will want a rif:text sort which is a lang-tagged string.

Yes, this would be a possibility.  However, in the RIF we might want to
have direct access to the language tag.

> 
>> [JB: For typed literals, I am not yet entirely sure about the embedding;
>> in my work on embedding RDF in F-Logic, I have not yet treated literals.
>>  Several issues come into play such as the special treatment of
>> rdf:XMLLiteral, and the semantics of other types which may or may not be
>> taken into account.  Therefore, the following is a rough first sketch of
>> the embedding.]
>>
>> For the embedding of typed literals "xxx"^^type-uri in RDF, the URI of
>> the type is used as the URI of the sort in RIF. rdf:XMLLiteral will have
>> to be declared a sub-sort of rdfs:Literal.
>>
>> tr_S maps typed literals "xxx"^^rdf:XMLLiteral where xxx is a valid XML
>> literal to symbols of the sort XMLLiteral: tr_S("xxx"^^XMLLiteral) =
>> "xxx"^^XMLLiteral
>>
>> tr_S maps typed literals "xxx"^^rdf:XMLLiteral where xxx is not a valid
>> XML literal to symbols of the sort rif:iri: tr_S("xxx"^^XMLLiteral) =
>> "\"xxx\"^^XMLLiteral"^^rif:iri [assuming the symbol \ is used for
>> escaping characters]
>>
>> tr_S maps typed literals "xxx"^^type-uri to symbols of the sort
>> type-uri: tr_S("xxx"^^type-uri) = "xxx"^^type-uri
>>
>> [JB: Note that type-uri will have to be declared as a sub-sort of
>> rif:iri]
>>
>>
>> == Embeddings of triples and graphs ==
>>
>> [JB: I use the frame syntax below; however, predicate syntax or slotted
>>  syntax could be used as well, since there is no disjointness between
>> sorts in RIF]
>>
>> An RDF graph S is a set of triples of the form (s,p,o), where s, p, and
>> o are RDF symbols. We extend the mapping function tr_S to embed triples
>> as RIF facts.
>>
>> tr_S maps triples (s, p, o) to RIF facts: tr_S((s, p, o)) = Forall
>> tr_S(s)[tr_S(p) -> tr_S(o)]
> 
> I've haven't yet seen the proposal for slotted notation for RIF Core.

In the slotted notation it would look like:

tr_S((s, p, o)) = Forall tr_S(s){tr_S(p) -> tr_S(o)}

In the standard relational notation it would look like:

tr_S((s, p, o)) = Forall tr_S(p)(tr_S(s), tr_S(o))


Best, Jos

> 
>> tr_S naturally extends to RDF graphs S: tr_S(S) = { tr_S((s, p, o) | (s,
>> p, o)\in S}
>>
>> == Embedding of the RDFS semantics ==
> 
> See earlier comments.
> 
> Cheers,
> Dave

-- 
Please note my new email address:
                         debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
In heaven all the interesting people are
missing.
  - Friedrich Nietzsche