Re: Timeline - editorial issues with docs - implementation

Jeremy -   Fast answer is I disagree that we cannot make a mid-Jan LC 
(and I think Guus with me).  You do have many valid points below, but 
I think most can be addressed by mid-Jan.  Anchors and cross links is 
something I agree with you on, and we need to get all the editors to 
do that.  Also, more members to do final read throughs, etc.  And as 
far as test/implementation goes, the plan is to use the Jan 9 f2f to 
get a lot of that worked out - we've even invited a couple of extra 
hackers to come and help.
  As far as links from our docs to RDF - this is one we need to work 
out - we don't want to link our LCs to their WDs, but if we link to 
the old rec, it's obviously a mistake.  I talked about this 
informally with Brian a while back, obviously we need to look at how 
best to do this, I'll talk w/Dan and Guus about it.
  However, one thing to consider - while we obviusly all want the best 
recommendation we can achieve, there's differences between ours, 
which is the first rec on a new language, and the RDF Core specs, 
which are cleaning up an existing rec.  In particular, I would expect 
the test cases on RDF Core to be more like a "compliance suite" than 
I would expect from ours - I think we should aim for tests that help 
elucidate complex language features (much like we already have).
  btw, you mention below "test case approval" - it's my understanding 
that the WG decided to make that essentially an editorial task (i.e. 
approve the whole test document) rather than approve individual ones 
-- I'd like to keep it that way, however I certainly hope at the Jan 
f2f you will go through this doc in some detail, working with the 
rest of the WG to make sure we have enough test cases to help 
developers in building tools for our language.
  You don't need to open an issue, discussion of releasing the LC 
documents will certainly be addressed with the WG.  It would be 
terribly ironic if HP, which is poised to have some of the best OWL 
tools in the shortest time, ended up objecting to LC, so definitely 
continue to work with us to get the best stuff we can out in a way 
that satisfies your company's needs.
  I am confused by the following:

>>I suggest the planned January publication should not be last call but should
>>be the editors' best efforts at last call ready documents with:
>>- spurious personal opinion deleted
>>- anchors added liberally
>>The main purpose is for an in-depth review by the WG and our friends, and
>>then we present more highly polished documents as a last call to the rest of
>>the world, a month or two later.

why can't we get those comments on our current WDs, particularly 
people letting us know where they'd like to see the the personal 
opinions deleted and the anchors added.  I've been disappointed by 
the lack of response to our current WDs - why do you think we would 
see more if we released a new version?  Why can't we get those same 
reviews from our friends for the current versions?  That was our 
intent in doing another round before LC when we did all our doc 
re-releases.

  -JH





  -JH



>I am still highly suspicious of the proposed timeline.
>
>I have significant concerns about:
>
>Document related:
>- the editorial quality of our docs
>   (sufficient to vote against last call)
>- lack of anchors in our docs.
>- the lack of cross links between our docs
>- the lack of links from our docs to the RDF docs
>- the lack of clarity as to when specs are informative or normative
>
>Implementation related:
>- the lack of implementation of: OWL Lite or OWL DL subset identification.
>- test case creation and approval
>
>In more detail:
>
>+ editorial quality
>Most of our WDs have a number of informal asides that are not, in my
>opinion, appropriate, in the final recs. Also the
>e.g.
>[[
>This syntax does not have to worry about any of the problems induced by the
>RDF triple model, including non-closed and ill-formed lists and
>restrictions. No parsetype extensions are needed for readability, and many
>issues of coordination with the RDF Core WG are not relevant at this level
>of syntax. Layering issues can also be safely ignored. Further, namespace
>issues can also be somewhat ignored; in the syntax here reserved words are
>not given with any namespace qualification
>]]
>says very little pertinent to a langauge specification.
>This reflects a lack of thorough review at that sort of level in the WG,
>because, quite rightly, we have been concentrating on the technical meat
>rather than presentation.
>
>
>+ lack of anchors in our docs.
>+ the lack of cross links between our docs
>In a multidocument recommendation it is important that the reader can
>navigate across the documents.
>This means that we need to have links from say the direct semantics of
>intersectionof, its abstract syntax, its mapping to triples, its feature
>synopsis, its treatment in the guide, its triple based semantics. Since
>*none* of these have anchors, we probably need to do this in two phases. (i)
>put the anchors in (ii) at the cross-links.
>
>+ lack of links between our docs and the RDF specs.
>There are a number of goals which we realize through using RDF. e.g. those
>to do with internationalization. If we do not link our concept of URIref and
>Literal to the RDF recs then we do not achieve those goals, and we have
>defined a langauge that is appropriate for deployment in the united states
>(only).
>
>+ the lack of clarity as to when specs are informative or normative
>
>e.g.
>[[ Properties may be stated to have ranges, (i.e., if X is related to Y by a
>property p with a range class, then Y must be an instance of the range
>class). For example, the property hasChild may be stated to have the range
>of Mammal. From this a reasoner may deduce that if Louise is related to
>Deborah by the hasChild property, i.e., Deborah is the child of Louise, then
>Deborah is a Mammal. Range is also a global restriction as is domain above.
>See the discussion below on local restrictions for more information. ]]
>I take this discussion from the features document to be informative, but
>that is my take - it is not clear in our recommendation.
>
>e.g.
>[[
>The semantics here starts with the notion of a vocabulary, which can be
>thought of as the URI references that are of interest in a knowledge base.
>It is, however, not necessary that a vocabulary consist only of the URI
>references in a knowledge base.
>]]
>Is that intended to mean anything for implementations? Is support for
>vocabulary other than that of URI references an OPTIONAL feature for OWL? I
>hope not.
>
>
>I suggest the planned January publication should not be last call but should
>be the editors' best efforts at last call ready documents with:
>- spurious personal opinion deleted
>- anchors added liberally
>The main purpose is for an in-depth review by the WG and our friends, and
>then we present more highly polished documents as a last call to the rest of
>the world, a month or two later.
>
>
>+ the lack of implementation of: OWL Lite or OWL DL subset identification.
>
>As far as I understand the implementation experience of the group is either
>RDF based or DL based. Our documents have the abstract syntax to triples
>mapping as a way of bridging these. Since RDF/XML is normative, it is the
>reverse transform that is crucial.
>All conformant implementation will need to be able to say whether an RDF/XML
>document is or is not an OWL Lite document. OWL DL and OWL Full
>implementations moreover need to be able to indicate whether an RDF/XML
>document is or is not an OWL DL document.
>I suspect that once we have such implementations, we may find that the
>abstract syntax is substantially more restrictive than we actually want.
>(e.g. the use of bnodes is very limited).
>
>
>+ test case creation and approval
>
>We do not have enough, and we have not spent enough time on agreeing or not
>the ones that we do have. (This is partly my fault).
>
>
>Finally: a process question
>
>We are about to close the last remaining issues - do I need to officially
>create some new ones e.g. "ISSUE editorial" to justify voting against a last
>call, which I certainly intend to do?
>
>Jeremy


-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Saturday, 7 December 2002 18:41:01 UTC