W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2011

Re: Preparing editor's drafts -- Q's for the team contacts

From: Ivan Herman <ivan@w3.org>
Date: Wed, 25 May 2011 15:03:34 +0200
Cc: Richard Cyganiak <richard@cyganiak.de>, RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <7FBBC3A9-6427-460F-BBE0-6320964A04FD@w3.org>
To: Eric Prud'hommeaux <eric@w3.org>

On May 25, 2011, at 14:43 , Eric Prud'hommeaux wrote:

> * Richard Cyganiak <richard@cyganiak.de> [2011-05-25 11:41+0100]
>> On 25 May 2011, at 11:34, Ivan Herman wrote:
>>> Ah, sorry, I misunderstood you. However.... (and here comes my ignorance with Mercurial): why do we need anything else than the Mercurial repository then? 
>>> 
>>> The practical issue is that if we define a directory under /2011/rdf for this, that area _is_ a CVS tree. Ie, editors would use CVS to update that directory. But, if so, why do we need Mercurial again?
>>> 
>>> (B.t.w., the RDFAWG uses CVS, so does the rdb2rdf and sparql groups. I would still have to understand what Mercurial brings us extra, apart from being more trendy...)
>> 
>> This is a cruel question. The only way to authoritatively answer it is by reliving a decade of traumatic memories. ;-)
> 
> If I understand correctly, mercurial has a more ambitious conflict resolution scheme (attempting each incremental patch constituting the document to be merged). This can accurately eliminate some conflicts.
> Mercurial's conflict resolution path used to require an odd to tell the system that the conflict is indeed resolved postponed conflicts (say, after you edit the <<<===>>>s). I don't know if that's still an issue.
> 

I can see the advantage of this (and other features of mercurial) if the issue is a larger development project in, say, software. But we are talking about documents with 2-3 editors, ie, 2-3 people who would really touch that stuff. This does not need some sort of a complicated conflict resolution...

AFAIK, using mercurial at W3C is a bit easier because setting up CVS access for people is a bit of a pain. 

Anyway, I do not want to get into the pros and cons of CVS vs. Mercurial. Whatever you guys feel more comfortable with, is fine with me...

Ivan


> Having worked with both, I have a marginal preference for Mercurial, but I want to caution Richard not to assume that a new administration will treat the prisoners much better.
> 
> 
>> Richard
>> 
>> 
>> 
>> 
>>> 
>>> Ivan
>>> 
>>> 
>>> 
>>>>> 1. We aim at a set of documents that fully and absolutely supersede the old documents. This means we'd continue to use the http://www.w3.org/TR/rdf-concepts/ for what we call the 'short URI' in our document management jargon with, of course, the 'dated URI-s' reflecting the current date. This means that, in future, if somebody uses the short uri as a reference, he/she will fall on the new version of the document.
>>>> 
>>>> I am in favour of that.
>>>> 
>>>>> Note that this may lead to some disruptions during the development process when users will suddenly find themselves reading working drafts. As an example, this is what the xml guys did: the http://www.w3.org/TR/xml/ URI leads to the latest (5th edition as of today) of XML.
>>>> 
>>>> I am *not* in favour of that. Some of the documents will go through a certain amount of churn, and the new features like multigraph might be in a rough state for a while, and I would not like people looking for a W3C REC to be presented with work in progress.
>>>> 
>>>>> I guess it may be possible to use a short name for the development time and change this on the last minute to switch to the old names
>>>> 
>>>> This sounds like a good solution to me.
>>>> 
>>>>> but I would not favour that, personally; it may become messy on long run.
>>>> 
>>>> What exactly is the concern?
>>>> 
>>>>> If we adopt a numbering (like the SPARQL and OWL have done), then we would probably use a different short name. If we just go for a 'second edition' then the XML approach might be the winning one.
>>>> 
>>>> I thought a bit more about this.
>>>> 
>>>> I guess we're going to want to say things like: “RDF (old) didn't have multiple graphs, but RDF (new) does.” Or “In RDF (old) this would have been two triples, but in RDF (new) it's just one.” Saying “first-edition RDF” and “second-edition RDF” doesn't seem quite right for something that actually includes relevant new features. Saying “RDF 1.0” and “RDF 1.1” seems more appropriate. So my vote is for RDF 1.1.
>>>> 
>>>> Thanks,
>>>> Richard
>>> 
>>> 
>>> ----
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> -ericP


----
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
Received on Wednesday, 25 May 2011 13:01:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:43 GMT