Re: implementation issues with b-node sharing (5.26 DL syntax)

Ian Horrocks wrote:

 > The problem with structure sharing would be finding the resource to
 > change S&AS (changes could be quite significant).

How about the text I proposed for section 4 i.e.
in S&AS 4.1
[[
Bnode identifiers here must be taken as local to each transformation, i.e.,
different identifiers should be used for each invocation of a transformation
rule.
]]

==>

[[
Bnode identifiers here are local to each transformation.
When the construct being transformed matches the *restriction* or
*description*
productions from the abstract syntax then
the bnode may be shared between multiple identical transformations of
identical
*restriction*s or *description*s. Otherwise the bnode used in each
transformation
should be unique for each invocation of a transformation rule.
]]


and in the proof a note:
[[
EDITORIAL NOTE: This proof has not yet been updated to reflect
the entirety of the last issue closed; in particular it does
not cover the case when multiple identical descriptions in the
abstract syntax map to the same blank node in an RDF graph.
]]

Does that look manageable?


> I don't recall saying anything about implementation experience in a
> telecon, but I did state at the editors meeting that I doubt if
> structure sharing would be problematic for implementations, that it
> would probably involve extra work to check that no such sharing was
> taking place, and that I doubt if many implementors would bother with
> such a check.
> 
> Sean and Raphael will be in a better position than me to confirm if
> this is really the case, e.g., in the species validator.
> 
> 
> Ian
> 


I think this gets to the heart of the matter - it is not whether B.1 B.2 is 
implementable, but whether the proposed text without B.1 and B.2 will be 
implemented.

The opinion that Ian expressed at the editors meeting was that few if any 
implementors would actually try and match the structures created by the 
going to Proposed Rec. The ability to distinguish the species of OWL is 
basic - without it, the utility of the semantic tools is not clear. 
Semantic layering depends on correct species identification.

If the specs and the implementations do not conform with each other then 
interoperability suffers.

I had made a number of proposals as to how to simplify these mapping rules 
(for DisjointClasses and EquivalentClasses) - none seemed to strike a chord 
with the rest of the group. Peter proposed the B.1 B.2 solution which did 
seem to be an improvement.

A problem I forsee in *not* having B.1 B.2 at this stage is that during 
Last Call we will have to reconsider - we have never had text that 
correctly describes the graphs produced by the mapping rules - we have 
never had sketches of implementations that could correctly implement these 
mapping rules in reverse. At last call, we may wish to be more conservative 
than we have to be now - currently Peter's proposal is the only candidate - 
during last call I think my proposal to change the mapping rules to 
duplicate the structures would be a smaller change that would be 
implementable - but it's not what the group wants.

On the other hand Jim's formal objection to owl:imports is a little lonely ...

Jeremy

Received on Tuesday, 25 March 2003 15:26:27 UTC