SV: Some good advice

> Fra: Lars Marius Garshol [mailto:lars.garshol@bouvet.no]
> Sendt: 13. oktober 2012 10:29
> Til: public-sdshare@w3.org
> Emne: Re: Some good advice
> * Inge Henriksen
> >
> > I want the SDshare specification work here  to get off to a good start, but
> > I'm already worried on the amount of focus there is here on how SDshare
> > will be physically implemented by the triplestores.
> 
> I think you make some good points here 

Thank you.

>,but at the same time I think it's
> legitimate to take care not too impose too heavy burdens on the
> implementors. 

Requiring the entities to be sorted before data syndication is not to put a "heavy burden" on the implementer, data sorting is something you learn very early in IT studies. 

> So our concern with sorting is that while it's easy to do the sorting when your
> SDshare source is a triple store, there may be other cases where it's actually
> very difficult. The example Graham puts forward (SDshare from a legacy
> RDBMS with separate changelogs in each table) I actually ran into myself at
> the social security service, and it's a tricky one.

If the sorting takes too "heavy burden" on your implementation then it is probably your software implementation pattern that needs refactoring. Our common goal here should rather be making a flexible specification and not limit it by imposing restrictions due to current hardware and/or software implementation issues.

 The whole Semantic Web specification stack is built on this idea; the semantic web/LOD does not currently scale very well - but those who know about Moores Law knows that sometime in no to distant the future it will.

> Another general concern is that we don't want to make SDshare too hard to
> implement, because if we do there won't be any implementations. 

I think you are mistaking to measure a "successful standard" linear to its commodification, I would rather focus on delivering some high-quality work and let the implementers worry about marketing. 

>I guess
> you could say we like the worse is better approach:
>   http://www.jwz.org/doc/worse-is-better.html

I can agree to the extent of delivering the absolute minimum required for a standard, but not to deliver something of bad quality with the aim to sometime fix it in the future. 
 
> > The only way I know to avoid this is to decide from the beginning of the
>> specification work to strictly take an academic approach and disregard
>> implementation issues - programmers are usually smart people and they will
>> figure it out somehow.
> 
> To some degree I agree

Good.

>, but at the same time you cannot discount
> implementation issues entirely. It's a tradeoff.

Standardization work is not meant to make it easy for the implementers, but (in our case) for the data consumers - in marketing language we could say that the "consumers" are our "customers" and not the "implementers". Should you care more about the (let's say) 10-100 implementers, or the potential millions of consumers - it is pretty clear to me that the consumers are the ones we should cater.

> 
> As for the political stuff, I once read a 10-point list on how to do successful IT
> standardization. The first point was "There will be politics. Deal with it." One
> always hopes to avoid it, of course, but in practice one is often disappointed.
> That's life, I guess.

Disregard implementation issues and there will be less politics, I can guarantee you that. I have seen implementers try to direct the standardization work to make their own implementation a standard - furiously combating any idea that would cause them to have to rewrite some of their code, and even leaving the standardization work when opposed. 

> Lars Marius Garshol  |  Consultant

Kind regards, Inge.

Received on Saturday, 13 October 2012 11:37:29 UTC