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

On Oct 15, 2011, at 12:01 , Ian Davis wrote:

> FWIW I find the term archaic slightly derogatory.
> 
> 

That was my feeling, too.

So, pushing the corpse into your courtyard:-): what would be a good English term for what we want, without being derogatory?

Ivan



> 
> 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
>> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf