Re: Alternatives to containers/collections (was Re: Requirements for a possible "RDF 2.0")

Hmm, very good points, Michael. I think Dave R. is on similar lines.

I feel like I need to go away and think about this more.

Pat

On Jan 16, 2010, at 7:22 AM, Michael Schneider wrote:

> Jeremy Carroll wrote:
>
>> Michael Schneider wrote:
>>>
>>> Ok, so I will tell you what /I/ want, and I will spell it out loud:
>>>
>>>    NO REMOVAL OR DEPRECATION (NOT EVEN "SILENTLY")
>>>    OF ANY FEATURE CURRENTLY EXISTING IN RDF!
>>>
>>> Isn't that a very simple rule?
>>>
>>> And I believe it matches quite well the first few mails in this  
>>> thread
>> which
>>> sounded to me as if many people "do not want to fix what isn't
>> actually
>>> broken".
>>>
>>>
>>
>> Michael that seems a little strong ... are you against deprecation in
>> the sense of discouraging use of some constructs that experience has
>> shown as not very helpful.
>
> In /my/ experience, you will find for virtually every RDF feature  
> some gang
> of people claiming that the feature is not helpful or even broken. For
> example, I am all for deprecating RDF/XML (but I would never come to  
> the
> insane idea to suggest this as a topic for a future RDF WG). So what  
> will be
> the criterion which features to deprecate and which not?
>
> For example, RDF reification is a regular candidate for being bashed  
> from
> all sides. But the vocabulary is actually used in practice. Just a  
> simple
> search with Sindice for "rdf:subject" results in more than 100  
> documents
> which include the term.
>
>  <http://sindice.com/search?q=rdf%3Asubject&qt=term>
>
> Do you want to tell me that all these uses aren't "helpful" to at  
> least
> *someone*? Or that the authors of these RDF documents were misguided  
> in some
> way when they decided to use the reification vocabulary?
>
> RDF reification almost made it into the OWL 2 spec to provide an RDF
> translation for two different language features. The encoding was  
> finally
> changed, so RDF reification isn't in the final spec, but the reasons  
> for
> this change were of different nature than "experience that  
> reification is
> not very helpful".
>
> There are also prominent supporters for RDF reification on the tool  
> front,
> and where real money is earned. For example, Topbraid Composer (TBC)  
> has
> dedicated support for this feature, and there has been quite some
> enthusiastic discussion on the TBC blog some time ago:
>
>    <http://composing-the-semantic-web.blogspot.com/2006_07_01_archive.html 
> >
>
>    In our recent modeling exercises with real-world customers
>    it became (once more) evident that reified relationships
>    are a key requirement in many domains. Reified relationships
>    are everywhere.
>
>> If we have broad consensus that some part of RDF was basically
>> ill-advised, then, sure, we don't want to break existing data, but we
>> don't have to commit to making more of the same.
>
> As you can see from my examples above, there is no such broad  
> consensus.
> There are just those same groups of people yelling aloud all the time
> against the features they dislike. Those who actually use those  
> feature will
> generally do not yell, because they don't have to -- unless the  
> features is
> eventually removed or deprecated.
>
> There are now many companies making money in some form or the other  
> from RDF
> and related technologies, there are highly budgeted long-time  
> projects being
> based on RDF, there are other standards depending on current RDF,  
> and there
> is a lot of RDF data out being already in some wide use. Dropping or
> deprecating features may easily have disastrous effects, and the
> distributedness and openness of the web makes it impossible to  
> foresee what
> or who will be affected. And I really see no strong pressure to do  
> such
> non-conservative changes, I just see a few ugly, maybe, but (almost)
> harmless warts on RDF's face.
>
> So not dropping/deprecating any feature from the normative standard  
> is the
> safe path that I am advocating.
>
> Michael
>
> --
> Dipl.-Inform. Michael Schneider
> Research Scientist, Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: michael.schneider@fzi.de
> WWW  : http://www.fzi.de/michael.schneider
> = 
> ======================================================================
> 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, RP Karlsruhe
> Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael  
> Flor,
> Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
> = 
> ======================================================================
>
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 17 January 2010 06:31:32 UTC