Re: completeness

On 22 Feb 2008, at 14:38, Michael Schneider wrote:

> Bijan Parsia wrote:
[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).

This was supposed to be an analogy (i.e., specing things that no one  
implements is analogous to having an ambiguity). But, now that I  
think about it, it seems even closer to an ambiguity. We *say* that  
the normative meaning is variable, but wink wink nudge nudge hint  
that implementations will do otherwise. This is not good!

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

I agree, in principle, but the question isn't just effort but quality  
of spec and fitness to purpose. If we cannot spec what implementors  
will do then there's no point to the spec at all, IMHO. We certainly  
can't meet our CR requirements in that case (two interoperable  
implementations) and furthermore, we might harm impelmentors (who  
don't realize that they should implement the informative bit and  
*not* the normative bit).

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

Sure. But it's really not that hard. One could handle it in the  
parsing phase, for example, by mapping them to unique URIs. The rest  
of the semantics would be exactly the same it would just turn out  
that all graphs are ground (under that semantics).

[snip]
>> 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,

Remember that I advocate for Skolem bnodes in OWL 1.1 DL as well.  
Plus, if you look at how BNodes work in tbox axioms in OWL 1.0 DL,  
you'll see, I think, that we already have something similar.

> and an OWL-1.1-Full with probably also
> existential bNodes in order to maintain backwards compatibility to  
> 1.0.

Well, in general, as I've said, I prefer backwards compatibility with  
actual practice than with prior specs. If we've specced something  
that no one has implemented, that's suggestive that it's shouldn't be  
carried forward.

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

It's already happened in SPARQL and will happen (afaict) in RIF. And  
it's happened in practice!

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

When you deal with legacy, things can be a bit confusing. But  
consider the case where you go through the effort of implementing  
variable semantics and then everyone tells you "But no one implements  
that and no one wants that. To be compatible you have to implement  
the informative stuff and really, only that." That's actually the  
case with RDF now!

(Pace we actually determine that the facts on the ground are as I  
believe they are.)

Cheers,
Bijan.

Received on Friday, 22 February 2008 15:06:34 UTC