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

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

Received on Saturday, 15 October 2011 09:41:32 UTC