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

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.

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

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

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

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.


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


>>4) Question on D-Entailment? Is that that simple-, RDF- and RDFS-entailment are 
>>parametrized with D, or D-entailment is a single separate entailment regime?
> 
> 
> D-entailment is a single separate entailment regime, extending  RDFS
> entailment.

ok, thanks for clarifying!

>>5) 
>>"whereas RIF has a fixed number of datatypes, so it essentially has a fixed datatype map. 
>>Combinations of RIF with RDF under D-entailment are only defined for the case where D 
>>corresponds to the fixed datatype map of RIF."
>>
>>I suggest to replace "fixed" by "dialect fixed datatype map" And note that the BLD
>>datatype map can be extended by dialects but that "D^<dialect>" mapes need to 
>>be defined by each dialect.
>>
>>This maybe raises an issue for extensibility how the Datamaps are defined for a dialect...
>>but well, there isn't much defined in terms of extensibility anyway so far.
> 
> 
> This text is obsolete, since RIF no longer has a fixed list.  I will
> update the document accordingly.

sure.


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

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

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


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


cheers
Axel


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Wednesday, 3 October 2007 17:54:30 UTC