Re: LC Issue timbl-01 choices

Apologies if this had been sent before. My mail system has been having 
some problems.
This was written  several says ago

This part of the conversation seems to be directed to the
director rather than the programmer.

Tim:

> [[
> Yes... the only logical thing is to remove it, and it would be easier
> earlier than later, but would involve of course changing RDF M&S.
> ]]
>

Brian:
>
> [[
> Might you be persuaded that in these circumstances, the best course of
> action is to leave it to a new, fresher WG to consider these issues and
> that that WG would be best placed to decide how to move current use to
> whatever solution they propose.

As programmer, I'd like to be able to claim conformance to something.
I don't want to have to implement a bunch of stuff which will
be taken out, or won't be used, for the sake of it conformance,
and a new working group seems a long way away.

As Director, I can only rely on the WG's own comments on its freshness 
or otherwise.
It does take a long time for a new group to come up to speed.
As Director, I wonder about whether the group can claim this part of
the spec to have reached its implementation requirement,
if the parsers parse the information but the semantics have not been
field tested.

It is a shame when a bunch of well-intentioned, intelligent and
hardworking people have to produce something which isn't as clean
as they would like.  Sometimes compromises are necessary, but
I am not sure that they are now.

(Remember the story of the man who wrote make(1) and a few
days later realized that the tab/space distinction in the Makefile
syntax was a mess, but didn't like to change it because by that time
several of his colleagues were using the syntax?)

So this is a question of getting things in perspective.

Removing reification:
Pro:  Simplicity of RDF.  Removal of misunderstood feature. Simpler 
parsers, etc
Con:  Worries about user community. Effort of removal of pieces from 
the spec (estimate?). Delay when WG is exhausted.

Leaving it in:
Pro: Easy - less work.
Con: Worries about justifying de-re semantics with examples of use.  
Confusion as to semantics. RDF reputation as obscure and complicated 
instead of simple.

Leave it to another group:
Pro: Easy - if you aren't in the other group
Con: Delay.  Change delayed is more difficult than change done now.

Would a compromise be to label it as deprecated?
Pro:  Document may not have to change now so much.  Parsers would be 
simple.  Those who use it would have something to refer to.
Con:   Still takes some document work.  "Half-pregnant" syndrome.

> In the meantime, the best strategy for the current WG is to reduce the
> prominence of the existing vocabulary, whilst at the same time 
> clarifying
> its specification for those who have chosen to use it.
> ]]

I feel that time spent explaining it is likely to give the wrong idea - 
that it is good to use.


> Graham/Jeremy: is there any chance you can propose a disposition for 
> this for Friday as well.
>
> Brian

Received on Tuesday, 8 April 2003 09:12:59 UTC