Re: ISSUE-77: Should we mark rdf:Seq as archaic (cf ISSUE-24)

FWIW I find the term archaic slightly derogatory.



On 15 Oct 2011, at 10:41, Dan Brickley <danbri@danbri.org> wrote:

> On 15 October 2011 09:32, Ivan Herman <ivan@w3.org> wrote:
>> 
>> On Oct 15, 2011, at 05:40 , Sandro Hawke wrote:
>> 
>>> On Fri, 2011-10-14 at 14:05 +0200, Ivan Herman wrote:
>>>> On Oct 14, 2011, at 13:15 , Dan Brickley wrote:
>>>> 
>>>>> On 14 October 2011 11:56, Steve Harris <steve.harris@garlik.com> wrote:
>>>>>> Not only that, it's actually useful.
>>>>>> 
>>>>>> There's only two (common) syntactic ways of expressing sequences/arrays/vectors, rdf:Seq and RDF Collections.
>>>>>> 
>>>>>> Both are pretty cumbersome, ugly, and arguably "broken" from some perspective, but as we don't have a valid replacement I don't think we should remove either one at the moment.
>>>>> 
>>>>> 
>>>>> Yup, sorry I forgot XMP briefly; but yes that + RSS1 are significant,
>>>>> even if "old fashioned". XMP in particular is very hard to update
>>>>> because the files are all out there in the wild. I'm not sure we gain
>>>>> much by making some of our biggest and earliest backers look retro.
>>>>> 
>>>>> Doing ordering in a binary relationship structure like RDF, especially
>>>>> with all the open-worldism and data mixing, is always going to be a
>>>>> challenge. We'd do better issueing friendly guidelines and examples
>>>>> and tutorials, than issuing grand proclamations about how people's
>>>>> REC-following data is broken / obsolete.
>>>> 
>>>> +1
>>> 
>>> I politely disagree.    I think Turtle makes RDF Collections seem quite
>>> nice, and hopefully that will quickly set the tone (perhaps with a
>>> little help from us) for APIs and SPARQL 1.2 (?) having nice list
>>> handling functions that are as efficient as native (non-destructive)
>>> list handling functions. (I hope some APIs do this already.)
>> 
>> Point taken. (Actually, at last in my view, RDFa 1.1 also adopted an additional feature whereby it is easy and natural to create lists.) But it is a bit of a problem that SPARQL 1.1 still does not cover list handling fully:-(
> 
> 
> SPARQL 1.2 nice list handling sounds great; but afaik is still
> vapourware. So I disagree politely with sandro's polite disagreement.
> 
> Actually I will refine my position (change my mind). I said it will
> 'always be' a challenge. These technology improvements show that it
> can get incrementally a bit easier, so I should soften that. However,
> merging lists, handling partially described real world lists, etc., I
> think does bring a certain unavoidable complexity.
> 
>>> Could that be done for Seq as well?  I don't think so, since there's no
>>> closing of the list.  So, we end up with one pretty-decent list
>>> mechanism, and one less-good one.   I think the only fair thing, in that
>>> situation, is to tell people that's what we've got.   And if you tell
>>> people they could use A or B, and A is better than B, that amounts to
>>> marking B as an Archaism.
>> 
>> Ok. I guess my problem is more a matter of wording, of public image. But if I try to put myself into the shoes of an Adobe representative who sells XMP to the world, I do not think I would like to announce a functionality that is labelled as 'archaic' by an international standard. That would not look very well, would it? Ie, it may be a matter of choosing another expression (do not ask me which one, my English is too poor for that...).
> 
> 
> Funny, I found 'archaic' gentler than 'deprecate' because the latter
> suggests to me that, through inaction, things could at some point soon
> stop working or cause errors or be 'removed' from the
> language/standard. Whereas archaic just says (to me), "ok, it's a bit
> old and we might have better ways of doing it now.". So yes the
> 'better' can look bad in PR terms; but the 'this might get removed'
> looks bad in business and engineering terms re costs and disruption.
> Either way, it's probably better to talk to them than try to guess,
> even for native speakers...
> 
> Dan
>