Re: RDF in RIF

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

The cost in simple entailment only comes from allowing variables in
queries (i.e. blank nodes in the entailed graph).  We are actually only
concerned here with the embedding of the entailing graph, so simple
entailment is the cheapest thing we can do.

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

Agreed.

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

Agreed; the scenario I had in mind was only about using an RDF graph as
background knowledge, whereas you are thinking about exchanging N3-like
rules, which is something we should also cater for.

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

In XSD strings, only characters matching the following production are
allowed:

	Char	   ::=    	#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF]

A comment says:
/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char


RDF literals can be any Unicode string.

http://www.w3.org/TR/rdf-concepts/#dfn-lexical-form

This would mean that the surrogate blocks, FFFE, and FFFF are allowed in
RDF literals.

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

Besides, the standard RDF semantics does take into account RDF literals,
but not XML schema datatypes (this is an optional extension).

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

OK.


Best, Jos

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