- From: Pat Hayes <phayes@ihmc.us>
- Date: Sun, 17 Jan 2010 00:30:26 -0600
- To: "Michael Schneider" <schneid@fzi.de>
- Cc: "Jeremy Carroll" <jeremy@topquadrant.com>, "Semantic Web" <semantic-web@w3.org>
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