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

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.

Dave