Are we superseding DCAT 1 or not once DCAT 2 is a REC? #1177

pwin · 2019-11-24T18:40:51Z

There is a status of recommendation document - "Recommendation Superceded" which is described at https://www.w3.org/2019/Process-20190301/#rec-rescind [there is interesting discussion about this at https://github.com/w3c/process/issues/36 ]

Please can we discuss here. Do we want to supercede DCAT v1?

makxdekkers · 2019-11-24T19:25:17Z

The question for me is whether there is a strong incentive to move people from DCAT1 to DCAT2. In my mind, DCAT1 remains valid and if people don't have a need for the new bits in DCAT2 (e.g. Data Services, geo-stuff, time intervals, qualified relations, packaging etc.), they may not need to upgrade.
So, I would say that we don't have to make DCAT1 a superseded recommendation, just link from DCAT1 to DCAT2 indicating that there is a newer version.

nicholascar · 2019-11-24T23:18:49Z

The PID URI for DCAT, https://www.w3.org/TR/vocab-dcat/, now redirects to DCAT 2. It means it's now no-longer possible to find DCAT 1 online. Is this as intended?

dr-shorthair · 2019-11-25T00:07:00Z

I'm leaning towards Makx view - perhaps with some nuances.

There is just one 'DCAT' and one dcat: namespace.
There are two descriptions of it, one which has additional features.
Existing DCAT users don't need to change anything to remain in conformance with DCAT.
The DCAT 2014 document describes what is essentially a 'profile' of (current) DCAT, which is currently reflected the DCATv2 document but will evolve more.

I wonder if a note could be added to DCAT 2014 explaining that it is a profile of DCAT?

dr-shorthair · 2019-11-25T00:14:32Z

It means it's now no-longer possible to find DCAT 1 online.

Apart from the DCAT 2014 document, @davebrowning does the NS document have a link to the old RDF representation?

davebrowning · 2019-11-25T06:35:47Z

It means it's now no-longer possible to find DCAT 1 online.

Apart from the DCAT 2014 document, @davebrowning does the NS document have a link to the old RDF representation?

The draft updated NS document (which isn't published yet) does have a link to a copy of the old rdf -which it assumes is renamed dcat2014.rdf (as per the naming in github).

Of course, we could make the "DCAT 2014 is a profile of DCAT" more explicit on that page.

davebrowning · 2019-11-25T06:42:47Z

The PID URI for DCAT, https://www.w3.org/TR/vocab-dcat/, now redirects to DCAT 2. It means it's now no-longer possible to find DCAT 1 online. Is this as intended?

That's a surprise to me at this stage in the process, so I certainly didn't intend that. [You can get to DCAT1 from the PR, of course but that's a bit silly] . I'd assumed that that wouldn't happen, certainly not till final publication and after this conversation.

Generally, I agree with the Makx/Simon approach, its just how we sign post that. (So I think that means we're not superceding.....)

akuckartz · 2019-11-25T07:08:01Z

Maybe DCAT1 can be declared deprecated as soon as DCAT2 has become a Recommendation?

andrea-perego · 2019-11-25T15:49:19Z

@pwin said:

There is a status of recommendation document - "Recommendation Superceded" which is described at https://www.w3.org/2019/Process-20190301/#rec-rescind [there is interesting discussion about this at https://github.com/w3c/process/issues/36 ]

IMO, stating that DCAT2 supersedes DCAT1 should not be a big problem (as DCAT2 is backward compatible with DCAT1). Said that, I am perfectly happy also with the other proposal, outlined by @makxdekkers in #1177 (comment)

I am more concerned about the issue reported by @nicholascar in #1177 (comment) :

The PID URI for DCAT, https://www.w3.org/TR/vocab-dcat/, now redirects to DCAT 2. It means it's now no-longer possible to find DCAT 1 online. Is this as intended?

I don't think this should be the right behaviour: the DCAT1 spec should be still accessible at its URL, and no redirection should be in place.

dr-shorthair · 2019-11-25T20:53:09Z

Yes - the /TR/ URI for DCAT 2 is https://www.w3.org/TR/vocab-dcat-2/
I think the URI for DCAT 2014 should be https://www.w3.org/TR/vocab-dcat/

nicholascar · 2019-11-25T23:34:14Z

So it looks like the redirect from https://www.w3.org/TR/vocab-dcat/ to https://www.w3.org/TR/vocab-dcat-2/ just needs to be broken and for https://www.w3.org/TR/vocab-dcat/ to have a note at the top as OWL Features does re OWL2: "New Version Available: OWL 2". There doesn't seem to be a status change from just plain Red in the OQL1 docs, just that note.

riccardoAlbertoni · 2019-11-26T16:55:49Z

I would in favour of "superseding" DCAT 2014. This, in my opinion, is not in contrast with Makx's view and does not force users to update, (I am afraid no one has such a strong power;)). Superseding DCAT 2014 do not remove DCAT 2014 from the web (the https://www.w3.org/TR/vocab-dcat/ remains available with a warning forwarding to the new specification), and the existing metadata descriptions which were compliant to DCAT 2014 will remain compliant to it.

However, It is important to make clear that we recommend the new solutions provided by DCAT 2 for requirements that were not considered or were underrepresented in the previous DCAT, such as those related to Data Services, geo-stuff, time intervals, qualified relations, packaging etc.
For the other cases, as pointed out by others "Existing DCAT users don't need to change anything to remain in conformance with DCAT.

agreiner · 2019-11-26T21:31:13Z

I agree with Andrea and Riccardo. Looking at the descriptions of the alternatives, it seems to be that "superseded" is what we're after.

"W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

W3C may declare a Recommendation Superseded if a newer version exists which the W3C recommends for new adoption. The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; only the name and explanation change.

W3C may rescind a Recommendation if W3C believes there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy and in particular section 5 (bullet 10) and section 7.5."

davebrowning · 2019-11-27T07:57:32Z

I've raised a separate issue for the DCAT 1 PID uri at #1182

pwin · 2019-12-02T11:19:44Z

I have mentioned to @plehegar that the consensus is to supercede version 1, and so we must now decide what text we include in version 1 to indicate this. https://www.w3.org/TR/2019/SPSD-WebCGM20-20191205/ is an example

What are your thoughts about what information must be present?

plehegar · 2019-12-02T13:45:45Z

some examples: https://www.w3.org/TR/hr-time-1/ , https://www.w3.org/TR/2019/SPSD-WebCGM20-20191205/ , https://www.w3.org/TR/html50/

agbeltran · 2019-12-03T10:32:48Z

I agree with the comments by Riccardo and Andrea, also having read the points that Annette highlighted from https://www.w3.org/2019/Process-20190301/#rec-rescind, as superseding means that we would recommend to use DCAT2 for new adoption.

I'd like to see some text clarifying that we are superseding but not making DCAT1 obsolete (as "A Recommendation can be both superseded and obsolete") and emphasise on the backward compatibility. I couldn't find anything around backward compatiblity in the Process Document either. The examples linked above don't seem to have any similar text, so we may need to write our own.

riccardoAlbertoni · 2019-12-09T17:43:11Z

I couldn't find anything around backward compatiblity in the Process Document either.

Well I think the first note in the Proposed Rec goes in that direction, see below

DCAT 2 maintains the DCAT namespace as it preserves backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break existing DCAT implementations.

Perhaps we might want to elaborate a little more on this, and move the note earlier in the document.

For example, saying

DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116]. It maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms.
Any new implementation is expected to adopt DCAT 2, while the existing implementations might not need to upgrade to it. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2.

agbeltran · 2019-12-09T18:01:27Z

I couldn't find anything around backward compatiblity in the Process Document either.

Well I think the first note in the Proposed Rec goes in that direction, see below

DCAT 2 maintains the DCAT namespace as it preserves backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break existing DCAT implementations.

I meant in the W3C Process Document (https://www.w3.org/2019/Process-20190301/#rec-rescind), not in the DCAT Proposed Rec

About your text - here it goes again with a few changes in italics:

"DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116], but it does not make it obsolete. DCAT 2 maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms.

Any new implementation is expected to adopt DCAT 2, while the existing implementations do not need to upgrade to it, unless they want to use the new features. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2."

What do you think?

pwin · 2019-12-09T20:29:51Z

Looks good Alejandra Perhaps we should also refer to the github issues and ask for a report should anybody experience any difficulties with this Cheers Peter

…

On Mon, 9 Dec 2019 at 18:01, Alejandra Gonzalez-Beltran < ***@***.***> wrote: I couldn't find anything around backward compatiblity in the Process Document either. Well I think the first note in the Proposed Rec goes in that direction, see below DCAT 2 maintains the DCAT namespace as it preserves backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break existing DCAT implementations. I meant in the W3C Process Document ( https://www.w3.org/2019/Process-20190301/#rec-rescind), not in the DCAT Proposed Rec About your text - here it goes again with a few changes in italics: "DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116], *but it does not make it obsolete*. DCAT 2 maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms. Any new implementation is expected to adopt DCAT 2, while the existing implementations *do not* need to upgrade to it, *unless they want to use the new features*. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2." What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1177?email_source=notifications&email_token=AAIFYTDCIKALF6FPL7C32S3QX2BXRA5CNFSM4JRAMA3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKCRRI#issuecomment-563357893>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIFYTHIPEDZNJI6FITIMWLQX2BXRANCNFSM4JRAMA3A> .

riccardoAlbertoni · 2019-12-09T21:13:34Z

@agbeltran wrote

What do you think?

I like it.
The only doubt is about the part "if they want to use the new features."

Let's consider an existing implementation in which a SPARQL endpoint is described in the old fashion DCAT style as embedded in a distribution instead of the DCAT 2 data service.

My opinion is that, in cases like the above, we should encourage to follow DCAT2 and then recommend to upgrade to DCAT 2 data service, while the sentence seems to leave this slightly open.

I guess that being DCAT 2014 not obsolete, the user can decide anyway not to stick to DCAT 2014, but he/she should be aware that this comes at the cost of being uncompliant with DCAT2.
Am I too restrictive?

Perhaps we might change "if they want to use the new feature." in "if they need to use the new features."?

makxdekkers · 2019-12-10T09:45:16Z

@riccardoAlbertoni @agbeltran & all,

I like Alejandra's version better, with the want instead of the need.

By the way, I find @plehegar's examples very confusing:

https://www.w3.org/TR/hr-time-1/ does not link to the new recommendation in the document metadata, the standard statements about the document, but just throws a red box with red text (is this WCAG2-compliant?) on the page, linking to the new version but omitting the 'Level 2' of the title of the new recommendation.
https://www.w3.org/TR/2019/SPSD-WebCGM20-20191205/ is even worse: I don't seem to be able to get to the document that supersedes this recommendation. The link to the latest WebCGM 2.0 links to itself, and the link to the latest WebCGM (2.1) links to a document with a date in 2010, not one in 2019, and version 2.1 does not even show that it has been superseded.
https://www.w3.org/TR/html50/ does have a link to the previous recommendation, but it links to a document that says it is not the latest version so I thought that was OK, but it turns out it does not link to the new 5.0 recommendation but to a later version of 4.01, and that one, https://www.w3.org/TR/html401/, does not link to HTML5.

So, no best practice there. I think W3C needs a clear policy for linking old and new recommendations.

makxdekkers · 2019-12-10T10:28:52Z

As I see it, documents published in the process of developing and maintaining evergreen recommendations take part in two chains:

the REC chain, i.e. REC1, REC2, REC3
the development chain, i.e. RECx comes about through WD1, WD2, .., CR, PR, REC

Both chains need to be reflected in a very clear way in the document metadata of every document in either chain.

In the REC chain there are several possible relationships between subsequent RECs:

the new REC is backward compatible with the old REC
the new REC is not backward compatible with the old REC (in which case, maybe the old REC is the end of its chain, and the new REC starts a new chain?)
the old REC is 'wrong' in some way and must be withdrawn or deprecated
maybe more?

These relationships could maybe be expressed with a controlled status vocabulary: under development, completed, superseded, deprecated, withdrawn etc.

How can we develop such a policy?

riccardoAlbertoni · 2019-12-10T16:33:38Z

@makxdekkers

@riccardoAlbertoni @agbeltran & all,

I like Alejandra's version better, with the want instead of the need.

Ok, let's keep Alejandra's revision, probably we cannot explain everything in once, and anyway, other parts of the document solves the concerns related to the example I was making.

PR for issue #1177

riccardoAlbertoni · 2019-12-13T11:19:31Z

Alejandra's revision is now merged in the document. Is there any other activity we need to accomplish before closing this issue?

plehegar · 2019-12-13T15:11:42Z

are we clear on what modifications we want to make to the DCAT 1 REC, if any?

dr-shorthair · 2020-01-15T00:00:48Z

I don't think we can or should make changes in DCAT1. But the version delivered by W3C should make it clear that it has been superseded - e.g. see what happens when you get https://www.w3.org/TR/2006/WD-owl-time-20060927/

andrea-perego · 2020-01-15T08:32:45Z

I concur with @dr-shorthair .

I would also like to mention that, in SpecRef, the key "VOCAB-DCAT" still returns the bib reference about the original version of DCAT. The fact that the URL included there (https://www.w3.org/TR/vocab-dcat/) points to DCAT2 is confusing for people.

See https://api.specref.org/bibrefs?refs=VOCAB-DCAT:

{
  "VOCAB-DCAT": {
    "aliasOf": "vocab-dcat",
    "id": "VOCAB-DCAT"
  },
  "vocab-dcat": {
    "authors": [
      "Fadi Maali",
      "John Erickson"
    ],
    "href": "https://www.w3.org/TR/vocab-dcat/",
    "title": "Data Catalog Vocabulary (DCAT)",
    "status": "REC",
    "publisher": "W3C",
    "deliveredBy": [
      {
      "url": "https://www.w3.org/2011/gld/",
      "shortname": "gld"
      }
    ],
    "versions": [
      "vocab-dcat-20140116",
      "vocab-dcat-20131217",
      "vocab-dcat-20131105",
      "vocab-dcat-20130801",
      "vocab-dcat-20130312",
      "vocab-dcat-20120405"
    ],
    "id": "vocab-dcat",
    "date": "16 January 2014"
  }
}

riccardoAlbertoni · 2020-01-15T10:33:15Z

I concur with @dr-shorthair .

I would also like to mention that, in SpecRef, the key "VOCAB-DCAT" still returns the bib reference about the original version of DCAT. The fact that the URL included there (https://www.w3.org/TR/vocab-dcat/) points to DCAT2 is confusing for people.

@andrea-perego
The dcat 2 bib ref is identified by vocab-dcat-2 see https://api.specref.org/bibrefs?refs=vocab-dcat-2

If I understand your point, you would like to have a URL consistent with this (i.e., the DCAT URL https://www.w3.org/TR/vocab-dcat-2/ instead of https://www.w3.org/TR/vocab-dcat/).
However, as far as I have understood reading issue #1182, we have to live with the fact that https://www.w3.org/TR/vocab-dcat/ points to the latest rec (see phillipe's comment ).

Or you were suggesting something else?
I apologize in advance if I am misinterpreting your comment.

agbeltran · 2020-01-15T10:38:20Z

I think that what @andrea-perego is pointing out would be solved by changing the href in https://api.specref.org/bibrefs?refs=VOCAB-DCAT to the specific DCAT 1 URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/

At the moment the href for "VOCAB-DCAT" is pointing to https://www.w3.org/TR/vocab-dcat/, which will always be the latest DCAT rather than the specific version one wants to point to.

andrea-perego · 2020-01-15T10:51:03Z

Thanks, @agbeltran . Yes, that would be an option. But, actually, I was not pointing to a specific solution - just reporting an inconsistency.

If VOCAB-DCAT should always refer to the latest version, this needs to be reflected in the corresponding bib entry in SpecRef, I guess, Of course, this will have a negative side effect in existing specifications using that key / URL to point specifically to DCAT 2014,

agbeltran · 2020-01-15T12:59:30Z

Yes, @andrea-perego the inconsistency is unfortunate.

But given that specs might have used VOCAB-DCAT and we won't want to break them, I am not sure if we could use the biblio reference VOCAB-DCAT for the latest version, but we will have to make sure it points to DCAT1.

Perhaps we should have an alternative key for the latest spec (e.g. VOCAB-DCAT-LATEST), even though it won't match the 'vocab-dcat' in the URL

riccardoAlbertoni · 2020-01-21T18:20:49Z

@agbeltran wrote:

Perhaps we should have an alternative key for the latest spec (e.g. VOCAB-DCAT-LATEST), even though it won't match the 'vocab-dcat' in the URL

It seems that the VOCAB-DCAT-LATEST is already foreseen and corresponds to https://www.w3.org/TR/dcat-voc/latest in the slides mentioned by Philippe, see also https://github.com/w3c/tr-pages/wiki/Latest-versions-proposal-for-leveled-specifications.

However, I haven't found a correspondent bib entry for https://www.w3.org/TR/dcat-voc/latest
The bibliographic entries for DCAT 1 are "vocab-dcat" and those with the date if the citer needs to distinguishing among the DCAT 1 versions (e.g., vocab-dcat-20140116)
while for DCAT 2 we have "vocab-dcat-2" plus those with the date.

riccardoAlbertoni · 2020-01-21T18:24:59Z

To get to a point with this issue, I would concur with @agbeltran's and @dr-shorthair's suggestions combined.

@dr-shorthair wrote:

I don't think we can or should make changes in DCAT1. But the version delivered by W3C should make it clear that it has been superseded - e.g. see what happens when you get https://www.w3.org/TR/2006/WD-owl-time-20060927/

@agbeltran wrote:

I think that what @andrea-perego is pointing out would be solved by changing the href in https://api.specref.org/bibrefs?refs=VOCAB-DCAT to the specific DCAT 1 URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/

That's what we can have according to the previous comments, and it does not break previous citations.

agbeltran · 2020-01-21T21:33:50Z

I agree with that approach.

Additionally, we should try to get VOCAB-DCAT-LATEST into the bibliography replacing the current VOCAB-DCAT

riccardoAlbertoni · 2020-01-21T21:41:37Z

I agree with that approach.

Additionally, we should try to get VOCAB-DCAT-LATEST into the bibliography replacing the current VOCAB-DCAT

I think vocab-dcat-latest should not be used as a bibliographic entry as it is going to change any time a new rec version is out ..

agbeltran · 2020-01-21T21:44:37Z

https://www.w3.org/TR/vocab-dcat/ always points to the latest spec, so VOCAB-DCAT-LATEST should include that href - as per comments above

andrea-perego · 2020-01-21T21:50:14Z

I think that, whatever the solution is/will be, this is not going to apply only to DCAT but to all TRs - as far as I know, so far citation keys always correspond to the last part of the URI, so I guess this is not going to change.

@plehegar , could you shed some light on this?

plehegar · 2020-01-23T13:25:35Z

Re https://api.specref.org/bibrefs?refs=VOCAB-DCAT , there is currently a bug in the W3C API See w3c/w3c-api#96 . Once the bug gets fixed, it will match https://www.w3.org/TR/vocab-dcat/ , and respec will point to the same place.

riccardoAlbertoni · 2020-01-24T11:46:11Z

This issue is on the hand of W3C, and we can't do much on it.

However, I think we might want to recheck how URL links and bibliographic refs work after DCAT 2 rec is published.
Shall we move this issue to the milestone of "future work"?

plehegar · 2020-01-24T19:39:59Z

SGTM. our webmaster is working on resolving the issue. I doubt it will get fixed by Jan 31 but hoping shortly after.

agbeltran · 2020-01-27T22:40:21Z

@riccardoAlbertoni if this is being handled, I agree with moving it to the "future work" milestone and deal with it after DCAT2 REC is public.

andrea-perego · 2020-01-28T08:33:32Z

+1 from me as well.

plehegar · 2020-02-04T18:34:30Z

https://www.w3.org/TR/vocab-dcat-1/ is now officially superseded.

I propose to close this issue. Note that the API bug remains (mismatch between /TR and API for "vocab-dcat"). If we want to track w3c/w3c-api#96 , we could open a separate issue in this repo.

nicholascar added the dcat label Nov 24, 2019

davebrowning mentioned this issue Nov 27, 2019

DCAT 1 PID URI incorrect #1182

Closed

andrea-perego added this to the DCAT2 ratification milestone Dec 3, 2019

riccardoAlbertoni mentioned this issue Dec 10, 2019

PR for issue #1177 #1190

Merged

riccardoAlbertoni added a commit that referenced this issue Dec 13, 2019

Merge pull request #1190 from w3c/dcat-issue1177

527b445

PR for issue #1177

riccardoAlbertoni modified the milestones: DCAT2 ratification, DCAT Future Priority Work Jan 28, 2020

agbeltran added the due for closing Issue that is going to be closed if there are no objection within 6 days label Feb 4, 2020

riccardoAlbertoni mentioned this issue Mar 10, 2020

Tracking the API bug (mismatch between /TR and API for "vocab-dcat") #1223

Open

riccardoAlbertoni closed this as completed Mar 10, 2020

Are we superseding DCAT 1 or not once DCAT 2 is a REC? #1177

Are we superseding DCAT 1 or not once DCAT 2 is a REC? #1177

Comments

pwin commented Nov 24, 2019

makxdekkers commented Nov 24, 2019

nicholascar commented Nov 24, 2019

dr-shorthair commented Nov 25, 2019

dr-shorthair commented Nov 25, 2019

davebrowning commented Nov 25, 2019 • edited Loading

davebrowning commented Nov 25, 2019

akuckartz commented Nov 25, 2019

andrea-perego commented Nov 25, 2019 • edited Loading

dr-shorthair commented Nov 25, 2019 • edited Loading

nicholascar commented Nov 25, 2019

riccardoAlbertoni commented Nov 26, 2019

agreiner commented Nov 26, 2019

davebrowning commented Nov 27, 2019

pwin commented Dec 2, 2019

plehegar commented Dec 2, 2019

agbeltran commented Dec 3, 2019

riccardoAlbertoni commented Dec 9, 2019

agbeltran commented Dec 9, 2019

pwin commented Dec 9, 2019 via email

riccardoAlbertoni commented Dec 9, 2019

makxdekkers commented Dec 10, 2019 • edited Loading

makxdekkers commented Dec 10, 2019

riccardoAlbertoni commented Dec 10, 2019

riccardoAlbertoni commented Dec 13, 2019

plehegar commented Dec 13, 2019 • edited Loading

dr-shorthair commented Jan 15, 2020

andrea-perego commented Jan 15, 2020

riccardoAlbertoni commented Jan 15, 2020

agbeltran commented Jan 15, 2020

andrea-perego commented Jan 15, 2020

agbeltran commented Jan 15, 2020

riccardoAlbertoni commented Jan 21, 2020

riccardoAlbertoni commented Jan 21, 2020

agbeltran commented Jan 21, 2020

riccardoAlbertoni commented Jan 21, 2020

agbeltran commented Jan 21, 2020

andrea-perego commented Jan 21, 2020 • edited Loading

plehegar commented Jan 23, 2020 • edited Loading

riccardoAlbertoni commented Jan 24, 2020

plehegar commented Jan 24, 2020

agbeltran commented Jan 27, 2020

andrea-perego commented Jan 28, 2020

plehegar commented Feb 4, 2020 • edited Loading

davebrowning commented Nov 25, 2019 •

edited

Loading

andrea-perego commented Nov 25, 2019 •

edited

Loading

dr-shorthair commented Nov 25, 2019 •

edited

Loading

makxdekkers commented Dec 10, 2019 •

edited

Loading

plehegar commented Dec 13, 2019 •

edited

Loading

andrea-perego commented Jan 21, 2020 •

edited

Loading

plehegar commented Jan 23, 2020 •

edited

Loading

plehegar commented Feb 4, 2020 •

edited

Loading