- From: Jim Hendler <hendler@cs.rpi.edu>
- Date: Fri, 22 Feb 2008 09:48:05 -0500
- To: Michael Schneider <schneid@fzi.de>
- Cc: Bijan Parsia <bparsia@cs.man.ac.uk>, OWL Working Group WG <public-owl-wg@w3.org>
+1 Sent from my iPhone On Feb 22, 2008, at 9:38, "Michael Schneider" <schneid@fzi.de> wrote: > 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 Stu > der > Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkra > us
Received on Friday, 22 February 2008 16:32:20 UTC