W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > April 2014

RE: ACTION-10 Possible contribution to the topic from DANS

From: <Manuel.CARRASCO-BENITEZ@ec.europa.eu>
Date: Wed, 9 Apr 2014 09:09:13 +0000
To: <christophe.gueret@dans.knaw.nl>
CC: <public-dwbp-wg@w3.org>
Message-ID: <39DB516E46C0E842A2CFFF1BBB7412F15F79C055@S-DC-ESTF03-B.net1.cec.eu.int>
Christophe,


From: Christophe Guéret [mailto:christophe.gueret@dans.knaw.nl]
Sent: Tuesday, April 08, 2014 2:04 PM
To: CARRASCO BENITEZ Manuel (DGT)
Cc: Christophe Gueret; public-dwbp-wg@w3.org
Subject: Re: ACTION-10 Possible contribution to the topic from DANS

Hoi Tomas,

The rationale:
  - Simple URIs  - shortening  services are a symptom of bad URIs
+1 though machines don't care as much about bloated URIs as we do ;-)

In the NeXT period, people talked about napkin transportable URI: something that one could write down in a napkin like a telephone number.

 - Previous versions - related to time or not
Yes, there could be anything that differentiate two instances of the (changed) same thing

Previous versions should be variants which can be addressed with different techniques including URIs
   http://example.com/foo          # the resource
   http://example.com/foo3        # the variant version 3 pointed to with a URI, but also it could be with the Header fields

https://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices#URI_and_HTTP


Version 3 could have the metadata time indicating when it was created.


 - Works with "file" and "http" - see MED https://joinup.ec.europa.eu/site/med


URI examples
   local
      file:///foo                                       # latest
      file:///foo3                                     # version 3

   network
      http://example.com/foo

      http://example.com/foo3

But then it's rather hard to see that 3 is the third version of "foo".

Here comes into play the Art of URI Construction: users will click on a page and people would learn how the URIs a constructed. Most user guessing's should be correct

   <a href="http://example.com/foo3">Once Upon a Time of Foo – Version Three</a>
   http://example.com/foo2


The construction rationale could be explained in a separated page.

E.g. is http://nl.dbpedia.org/resource/Ww2 the version 2 of http://nl.dbpedia.org/resource/Ww ?

There are also some organisations that use the date as versions, with for example http://www.w3.org/TR/vocab-data-cube/ for the latest version of something and http://www.w3.org/TR/2014/REC-vocab-data-cube-20140116/ or http://www.w3.org/TR/2013/PR-vocab-data-cube-20131217/ for specific versions. That sounds like a good idea ;-) - but, again, can be hard to parse


Name-dropping :-)   I am a friend of Larry Masinter
   http://larry.masinter.net


Long-term archiving is one of his pet subjects
   http://larry.masinter.net/0603-archiving.pdf

Thanks for the pointer! I'll have a look.
Just one more pointer: he is one of the co-authors of http RFC
Regards
Tomas
Regards,
Christophe


Regards
Tomas

From: Christophe Guéret [mailto:christophe.gueret@dans.knaw.nl<mailto:christophe.gueret@dans.knaw.nl>]
Sent: Tuesday, April 08, 2014 11:24 AM
To: CARRASCO BENITEZ Manuel (DGT)
Cc: Christophe Gueret; public-dwbp-wg@w3.org<mailto:public-dwbp-wg@w3.org>
Subject: Re: ACTION-10 Possible contribution to the topic from DANS

Hoi,
Ok. So we may be onto something slightly different then... regarding your example, the temperature in Luxembourg the 2003-04-08 would most likely be fetched out of a preserved data set that contains the daily temperatures. This dataset would be preserved at, say, DANS and contain only "http://example.com/lu" URIs in it (just like every new version of DBpedia still use exactly the same URIs for the resources it contains). Then we would more likely build something like http://example.com/dataset/UUID?http://example.com/lu, the UUID being that of the dataset which contains the description of the temperatures on 2003-04-08.

But the two problems I have with this approach are:
* The use of a parameter for the request, this makes it easier that trying to split the URI but it not as neat as having just a plain URI. In this respect, we are also looking at the IETF DURI draft (https://tools.ietf.org/html/draft-masinter-dated-uri-10) to provide a nicer dated scheme for URIs. But then we would need a dereferencing service for those DURI who is likely to take them as a GET parameter... so we just shift the issue :-\
* In order to just deliver the preserved data as it was preserved, the description should still describe http://example.com/lu and thus not take into account the fact that it is a different time-located version of the description that is being returned. We could rewrite the description on the fly but that's not a good practice wrt preservation. Maybe embedding the description into another that described the archived resource, and package the whole thing with provenance info would be a good fix there...
Cheers,
Christophe

On 8 April 2014 11:10, Manuel.CARRASCO-BENITEZ@ec.europa.eu<mailto:Manuel.CARRASCO-BENITEZ@ec.europa.eu> <Manuel.CARRASCO-BENITEZ@ec.europa.eu<mailto:Manuel.CARRASCO-BENITEZ@ec.europa.eu>> wrote:
Christophe,

Yes. More: an example

Temperature in Luxembourg today - dynamic URI
  http://example.com/lu


Temperature in Luxembourg the 2003-04-08 - static URI
  http://example.com/lu/2003-04-08 - static URI

Regards
Tomas

From: Christophe Guéret [mailto:christophe.gueret@dans.knaw.nl<mailto:christophe.gueret@dans.knaw.nl>]
Sent: Friday, April 04, 2014 3:36 PM
To: public-dwbp-wg@w3.org<mailto:public-dwbp-wg@w3.org>
Subject: ACTION-10 Possible contribution to the topic from DANS

Hoi Manuel, everyone,
We've added a bit about data preservation at DANS in the use-case document:
https://www.w3.org/2013/dwbp/wiki/Use_Cases#Digital_archiving_of_Linked_Data

Does this go along the lines of what you wanted to discuss with this action ?

Christophe


--
Onderzoeker
+31(0)6 14576494
christophe.gueret@dans.knaw.nl<mailto:christophe.gueret@dans.knaw.nl>

Data Archiving and Networked Services (DANS)
DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op www.dans.knaw.nl<http://www.dans.knaw.nl> voor meer informatie. DANS is een instituut van KNAW en NWO.

Let op, per 1 januari hebben we een nieuw adres:
DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB Den Haag | +31 70 349 44 50 | info@dans.knaw.nl<mailto:info@dans.knaw.nl> | www.dans.knaw.nl<http://www.dans.knaw.nl>

Let's build a World Wide Semantic Web!
http://worldwidesemanticweb.org/


e-Humanities Group (KNAW)



--
Onderzoeker
+31(0)6 14576494
christophe.gueret@dans.knaw.nl<mailto:christophe.gueret@dans.knaw.nl>

Data Archiving and Networked Services (DANS)
DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op www.dans.knaw.nl<http://www.dans.knaw.nl> voor meer informatie. DANS is een instituut van KNAW en NWO.

Let op, per 1 januari hebben we een nieuw adres:
DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB Den Haag | +31 70 349 44 50 | info@dans.knaw.nl<mailto:info@dans.knaw.nl> | www.dans.knaw.nl<http://www.dans.knaw.nl>

Let's build a World Wide Semantic Web!
http://worldwidesemanticweb.org/


e-Humanities Group (KNAW)



--
Onderzoeker
+31(0)6 14576494
christophe.gueret@dans.knaw.nl<mailto:christophe.gueret@dans.knaw.nl>


Data Archiving and Networked Services (DANS)

DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op www.dans.knaw.nl<http://www.dans.knaw.nl> voor meer informatie. DANS is een instituut van KNAW en NWO.



Let op, per 1 januari hebben we een nieuw adres:

DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB Den Haag | +31 70 349 44 50 | info@dans.knaw.nl<mailto:info@dans.kn> | www.dans.knaw.nl


Let's build a World Wide Semantic Web!
http://worldwidesemanticweb.org/


e-Humanities Group (KNAW)
[Image removed by sender. eHumanities]<http://www.ehumanities.nl/>


image001.jpg
(image/jpeg attachment: image001.jpg)

Received on Wednesday, 9 April 2014 09:09:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:12 UTC