Pat Hayes wrote: > > On Jan 15, 2010, at 4:39 PM, Michael Schneider wrote: > >> Sampo Syreeni wrote: >> >>> On 2010-01-15, Pat Hayes wrote: >>> >>>> Well, simple rules are sometimes good guides to behavior. I take it >>>> that you would prefer the much more complicated advice, to let it all >>>> hang out. >>> >>> As for me, I'd make it straight. What do we want from the standard? >>> Spell it out loud, now, >> >> 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". > > But some of it IS broken. The plain-literal/xsd:string mixup is broken. > The special status of rdf:XMLLiteral is broken. Containers are broken, > they were broken from the get-go. (Not collections, ie lists, which are > ugly but useful.) IMO, rdf:seeAlso is broken, because although it does > get used, the uses are nowhere even remotely compatible with one > another. Reification is broken, because it has never been given a > satisfactory semantics. (I would bet a good beer that there isn't a > single deployed use of RDF reification that strictly conforms to what > the spec says about it, normatively.) Arguably, the whole business of > D-interpretations for datayping is broken: not because its actually > wrong, but because nobody pays it any attention. What everyone actually > does is simply assume that the XML schema datatypes are built-in as a > part of RDF, which is probably what we should have said in the spec > itself, instead of trying to be "general-purpose" about datatyping. IMO, > the RDF/RDFS distinction is broken, but maybe we should just not go > there, I admit. I agree with all of those and could add a few more. However, my point is not "there is nothing to improve" but "it's not clear that fixing those things will make a substantial difference to uptake and so worth the investment - right now". At the risk of repeating myself ... before contemplating an RDF 2.0 (or even a 1.1) I'd like to hear the evidence that some group of applications or users is unable or unwilling to work with RDF, or being significantly held up, because of a specific set of mis-features or missing features. Then if that leads to enough justification for an RDF 2.0 then other clean ups can be considered as well. So far (though I may have missed a lot in this explosion of emails) I've noticed a couple of things in the "holding things up" category. o Several groups find a need to serialize named graphs for backup, exchange and provenance purposes. So maybe standardizing a Tri* format of some sort would be useful. However, lack of update of the existing proposals suggests the need is modest and in any case that sounds like a separate spec not a revised RDF spec. o There does seem to be evidence that the XML syntax has been a barrier to uptake for some groups. Though I've reservations about W3C developing yet another RDF syntax. A lot of the other issues may well be broken features but they are not a problem. I.e. they are not what stops people using RDF and when people do use it they work with or around them without massive difficulty. DaveReceived on Saturday, 16 January 2010 12:27:01 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:05 UTC