RE: completeness

Bijan Parsia wrote:

>> So, as you say, when bNodes are alternatively seen as (local) names  
>> instead
>> of existentials, then a polytime decision algorithm exists for pD*
>> entailment. Then, of course, pD* isn't a real RDFS extention  
>> anymore. So I
>> wouldn't spec this, if pD* or a sublanguage is going to be 
>an OWL-Full
>> fragment.
>
>Why not? I point to the HTML5 design principles document (which  
>contains, I think, useful advice):
>	
>http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>Fidelity to prior specs is *much* less important that actually  
>describing what implementors will do.
>
>Oh, "as an OWL-Full fragment". 

Yes, that too. But I also talked about pD* as an "RDFS extention" above. :)

>Well, it's still a fragment of OWL-Full in the sense of having "if" and not
"iff" semantics in pretty  
>much the way Pd* does for other constructs.
>
>> But seeing bNodes as local names may of course become a typical
>> non-standard restriction in reasoners for this language.
>
>"Typical non-standard" seems like a "spec smell" to me. 

Ok, granted! Might be a misnomer, at least I don't like this notion, too.

>If it's typical, let's standardize it. 
>
>In fact, this is more than typical:  
>It's ubiquitous.
>
>> And this might even
>> be mentioned in an informative section of a spec. Just an idea.
>[snip]
>
>Though some people have tried to cast me otherwise, I'm really  
>eminently pragmatic: I prefer whatever it takes to make specs clear  
>and useful. I also prioritize clarity over general accessibility,  
>since the people who make the effort to understand can explain it to  
>others. But if the spec is unclear or ambiguous, then no one can  
>settle disputes. 

It wouldn't become ambiguous, since I suggested that there would be a
normative part (existentials) separated from an informative part (skolems as
a meaningful alternative).

>Similarly, specing things which no one implements is 
>a waste of time and can lower the perceived value of the spec (and  
>thus implementor efforts to adhere to the spec).

I will only make a statement about the "specing complexity" here.

For the WG, I think the least effort will be to simply have an OWL-Prime
with bNodes as existentials. For this to achieve, all we have to do is
writing down a single sentence at the top of the OWL-Prime semantics spec:

  "This model-theoretic semantics for OWL-Prime
  is an extension of the model-theoretic semantics for RDFS."

together with a reference to

  <http://www.w3.org/TR/rdf-mt/#DefSemanticExtension>

This copycats the way how current OWL-Full is made a semantic extention of
RDFS. By this, all model-theoretic semantic conditions (and indirectly all
triple entailment rules) of RDFS automatically are inherited by OWL-Prime.
This includes, of course, the existential semantics of RDFS. We then only
need to define the remaining model-theoretic semantic conditions and triple
rules which are specific to OWL-Prime. And in the best case, we can even
simply take them from the pD* paper.

If we instead were about switching to skolem semantics, then we would
certainly need to do more work. We cannot just point to RDFS semantics and
say something like "this all, but without bNodes as existential". This is
not sufficient for a rigorous specification of OWL-Prime's semantics.
Instead, we would essentially have to redefine the whole RDFS semantics,
both model-theoretic semantic conditions and triple rules, but this time
carefully checking that bNodes are now interpreted as skolems. This may or
may not be an easy task, I cannot say at the moment. It is certainly a bit
error-prone, and it would make the document for OWL-Prime a lot larger.
There would then be a lot of redundancy between two RDF related semantics
documents, the RDF(S) spec, and the OWL-Prime spec.

>So I would put it the other way around: If what implementations need  
>and users want is bnodes as names, let's make *that* the specced  
>version. One can always provide informative text telling people how  
>it connects to OWL Full's semantics. However, I don't care, though I  
>strongly recommend against, making that bit normative as well as long  
>as implementations can clearly opt out of the part that they will opt  
>out of anyway.

Another thing, which I would feel uneasy with, would be a situation, where
we have an RDFS with existential bNodes, an OWL-Prime with skolem bNodes, an
OWL-1.0-Full with existential bNodes, and an OWL-1.1-Full with probably also
existential bNodes in order to maintain backwards compatibility to 1.0. It's
not that I am a big fan of bNodes as existentials, that's really not the
case. But if this is going to change, then I would prefer to see it changed
for the whole family of RDF-based languages, not just for one or two family
members. Even if I was an implementor, this would really be more confusing
to me than bNodes as existentials, but then consistently over the whole
language family at least.

Cheers,
Michael

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus