Re: [BLD] some more commments which I didn't manage to type in yesterday...

Axel Polleres wrote:
> some comments to the comments...
> 
> Jos de Bruijn wrote:
>> Axel,
>>
>> Thanks for the comments.  Find replies in line.
>>
>>
>>> Starting off from Section 4
>>>
>>> 1)
>>> "*** The working group will have to decide whether to specify
>>> compatibility with both OWL DL and Full, or with just one of the two.
>>> [...]"
>>>
>>> Why? another option is differenct dialects for different OWL dialects.
>>
>>
>> I'm not sure what you mean with "different dialects" here.  The document
>> is the BLD specification, so the question is wedge which species of OWL
>> we define compatibility.
> 
> indeed, but as OWL itselfg comes in three different dialects, it will
> IMO not possible to treat them all in one RIF dialect, so, either
> we indeed just decide for one, as you seem to suggest, or we suggest
>  BLD_{OWL DLP}
>  BLD_{OWL Horst}
>  BLD_{OWL Light}
>  BLD_{OWL DL}
>  BLD_{OWL Full}
> "subdialects" parametrized with compatibility notions for those OWL
> Dialects.

I don't like this notion of a multitude of dialects; this just makes
things far too complicated. I also do not really see any obvious
criteria we could use for identifying these dialects, apart from the
distinction horn/not horn, which basically boils down to OWL DLP/DL (in
case we go for compatibility with OWL DL) and OWL Horst/Full (in case we
go for compatibility with OWL Full) (by the way, I don't like OWL Horst,
because it is a semantic restriction of OWL).

> 
>>> 2)
>>> "For example, direct rule-based processing can be done by suitably
>>> restricting the OWL component to a so-called DLP subset."
>>>
>>> to be fair, we should state as well:
>>>
>>> "or restricting the rules part to e.g. DL-safe rule"
>>
>>
>> No direct rule-based processing is possible in the case of OWL DL +
>> DL-safe rules, and certainly not within the bounds of BLD.
> 
> ok, now I got what you want to say
> 
>>> However, we should check here whether and how we interfer with the
>>> new OWL WG charter, since they were talking about such extensions.
> 
>> As I understand the OWL 1.1 charter [1], rules are not in their scope.
>> They do expect "To help produce the RIF Working Group deliverable on
>> using RIF with OWL and generally avoid unnecessary difficulties for
>> users working with RIF and OWL in combination".
>>
>> [1] http://www.w3.org/2007/06/OWLCharter
> 
> Ok, in the OWLED meeting in Innsbruck (which certainly is a different
> issue thant the now active working group), I had the impression that
> what they want to go for in this dierection is a "stamp" for DL-safe.
> Anyway, htey can always define dialects for that.


What "they" want is different from what the charter is of a working group.
DL-safe rules  are simply a syntactic restriction on the case of
combination with OWL DL; the semantics are strictly FOL.  If we are
going to support OWL DL, then I certainly want to mention this
particular restriction.  We might even want to include particular
support for it in the language ( i.e. adding implicit predicates to the
rules which have forced this restriction ).

> 
>>> 3)
>>> "a) There are no requirements on the shape of the OWL DL ontology. b)
>>> RIF recommends to use only the DLP subset of OWL DL in combination
>>> with RIF; anyone wanting to go beyond this subset is on their own
>>> wrt. processing. c) RIF only defines the combination for the DLP
>>> subset of OWL DL."
>>>
>>> Again, an alternative would be to do own dialects for these options.
>>
>> But which option do we choose for BLD?
> 
> I'd suggest for BLD to focus (at least for the beginning) on two
> Subdialects:

Again, I do not like specifying all kinds of sub dialects. We should
make it easy for the user to use RIF in combination with OWL.

> 
>  BLD_{OWL DLP}   (the Horn fragment of OWL DL, as defined in [1])
>  BLD_{OWL Horst} (the Horn fragment of OWL Full, as defined in [2,3])

This is not really a fragment, because it is a semantic, rather than
syntactic, restriction.  The same language construct has a different
meaning in OWL Horst than in OWL Full.

> 
> These two seem to be feasible almost straightforwardly (if no, I would
> be interested in objections).
> In case, we allow powerful enough built-ins to express hex-atoms,
> we could also define a combination to allow DL-atoms as suggested in [4]
> we could also define such a combination, restricted to Horn rules.

This is one of the possibilities mentioned in the choices for the
semantics of the combination (choice 2 in both semantics sections ).

> 
> 
> 1. Benjamin N. Grosof, Ian Horrocks, Raphael Volz, Stefan Decker:
> Description logic programs: combining logic programs with description
> logic. WWW 2003: 48-57
> 
> 2. Herman J. ter Horst: Combining RDF and Part of OWL with Rules:
> Semantics, Decidability, Complexity. International Semantic Web
> Conference 2005: 668-684
> 
> 3. Herman J. ter Horst: Completeness, decidability and complexity of
> entailment for RDF Schema and a semantic extension involving the OWL
> vocabulary. J. Web Sem. 3(2-3): 79-115 (2005)
> 
> 4. Thomas Eiter, Thomas Lukasiewicz, Roman Schindlauer, Hans Tompits:
> Combining Answer Set Programming with Description Logics for the
> Semantic Web. KR 2004: 141-151
> 
 >>> 6) "
>>> A typed literal (s, u) is a well-typed literal if
>>>   1. u is in the domain of DRIF and s is in the lexical space of DRIF(u)
>>>   2. u is the URI of a symbol space defined by RIF and s is in the
>>> lexical space of the symbol space, or
>>>   3. u is not in the domain of DRIF and is not a symbol space defined
>>> by RIF.
>>> "
>>>
>>> what is the diff betwen 1. and 2., don't they subsume each other?
>>
>>
>> RIF defines only 2 symbol spaces (rif:iri and rif:local), which are not
>> data types.
> 
> Which is kind of confusing, IMO. Anyway, then, not better reorder 1. and
> 2. since 1. seems to be the most "basic" one?

OK

> 
>>>
>>> 7) "
>>> VU* is obtained from VU by replacing every RDF URI reference URI in
>>> VU with "URI"^^rif:iri.
>>> "
>>>
>>> How would we treat RDF typed literals... being typed by "rif:iri" (or
>>> "rif:text") then
>>> wouldn't that be ambiguous?
>>
>>
>> There is no ambiguity. RDF literals typed with rif:iri are simply
>> interpreted as arbitrary objects. 
> 
> but wouldn't they be the same as rdf resources then?

I do not follow.  Everything in RDF is a resource (also every literal).

Maybe the confusion stems from the fact that not every typed literal is
interpreted as a literal (i.e. as belonging to a set LV).

> 
>> rif:text is a well-defined datatype
>> which is interpreted accordingly.
> 
> ... I mean here that it seems that some typed literals and resources
> get, by this, the same meaning in RIF duddenly, which they didn't have
> in RDF beforehand, e.g.
> 
>  <a> <b> <c>.
> is not the same as
>  <a> <b> "c"^^rif:iri.
> in RDF, or
> 
>  <a> <b> "c"@en.
> is not the same as
>  <a> <b> "c@en"^^rif:text.

Correct.  And I claimed that this is exactly what you want (i.e. that
these are the same in an RIF-RDF combination). RIF defines the rif:iri
symbol space and the rif:text datatype.  So, when combining RIF and RDF,
the definition of the rif:iri datatype should be respected.
The case of rif:iri is not so clear cut, because RDF does not have the
concept of symbol spaces.  However, I do not see any other reasonable
way to interpret the "c"^^rif:iri; in fact, I would find it rather
strange if an IRI <c> is interpreted differently from the symbol
"c"^^rif:iri.

> 
> 
>>> 8) Is the @@ encoding within rif:text not superfluous? The last @
>>> always identifies the separation.
>>
>>
>> It is indeed superfluous. the definition of the datatype will be updated
>> accordingly.
>>
>>
>>> A cleaner/simpler solution would be:
>>>
>>> Define for each lang tag an XML simple type as a subtype of rif:text
>>> e.g
>>> rif:text@en
>>> rif:text@de
>>> ...
>>> and use those types
>>
>>
>> It is not clear how to refer to such simple types.  Furthermore, we
>> would have to define a very large number of such data types.
> 
> for all language tags, yes. Anything more?

I still do not see how XML simple types could help us (you did not
address my concerns about identification). Besides, the list of language
tags is not fixed; it is even possible to invent your own language tags,
according to RFC 3066 [1].

best, Jos

[1] http://www.isi.edu/in-notes/rfc3066.txt
-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
The third-rate mind is only happy when it is
thinking with the majority. The second-rate
mind is only happy when it is thinking with
the minority. The first-rate mind is only
happy when it is thinking.
  - AA Milne