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

Received on Saturday, 16 January 2010 12:27:01 UTC