W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

Re: Issue rdfms-abouteach

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Fri, 16 Nov 2001 12:10:35 +0000
To: Patrick.Stickler@nokia.com
cc: w3c-rdfcore-wg@w3.org
Message-ID: <20561.1005912635@tatooine.ilrt.bris.ac.uk>
>>>Patrick.Stickler@nokia.com said:


> Rather, I will restate that I am opposed to the removal
> of this feature, and will not likely be swayed unless 
> implementors of RDF parsers can clearly explain to me
> that it is a major pain in the rear end for them.

The evidence is clearly explained in the first email I posted on this:


Hilighting comments from implementors
   myself: For streaming parsers (most of them), it sucks.  Kill it.
           Nobody ever complained my parser didn't implement it.

      "my short answer is that it should be removed from the core RDF
       and if it is indeed useful it could be layered on top of the core."
      -- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Jun/0008.html

      and the issue he raised

     various messages including

     "The main reason for dropping aboutEach, which isn't such a bad
      one, is that the corner cases to do with aboutEach are unclear
      (in a range of issues raised in part by me)."
     --  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0524.html

     Nobody ever complained Jeremy's parser didn't implement it efficently.

I found another one:
   Gabe Beged-Dov:
   "In general, I [...] think it is very important that there be a
   well thought out alternative to aboutEach and aboutEachPrefix that
   is processed at a layer downstream from the parser." 
    -- http://gabesemanticweblog.editthispage.com/stories/storyReader$9

The major evidence for me is:
   * Many existing, deployed RDF systems never used it
   * Many implementations never saw a need to implement it

These are primarily the same reasons we killed aboutEachPrefix months ago

It is a major pain in the rear end for me.

Received on Friday, 16 November 2001 07:10:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC