Re: RDF in RIF

Jos de Bruijn wrote:
> 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?

I wasn't even meaning simple entailment due to the cost.

>> 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.  

Exactly.

> Therefore, we should probably simply use the sort
> rdfs:Resource, and make rif:iri a sub-sort.

OK.

>>> 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.

That too, but I was particulal thinking about issues of round tripping 
languages like JenaRules and N3 through RIF. We quite often write rules 
which will deduce new RDF triples involving bNodes. It would be 
noticeably more convenient if the skolem constants corresponding to the 
intended bNodes were separable from any other rif:iri.

> 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.

Fair comment but doesn't completely avoid the issue.

>>> 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,

I don't think so. It was a last minute decision of RDF Core to make sure 
that non-lang-tag plain literals and xsd:strings are (semantically) 
interchangeable. Is there some test case which shows a difference?

> 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).

Good point, I'll have to think about that.

>>> [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.

Sure that could be an operation on the literal, just as it is in SPARQL.

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

Received on Thursday, 31 May 2007 21:29:43 UTC