[Puneet Kishor]

Hi Enrique,
Please see inline below:
Hi Enrique,
Please see inline below:
> On Nov 14, 2015, at 7:43 PM, Enrique Alonso García wrote:
>
> ..
>
> Concerning this debate, it is obvious that not only these problems but many others arise when legal interoperability moves from access to data and easy and simple databases to accessing data through “open databases”, web services or e-infrastructures. When the second happens, new different issues of liability arise (or inevitably sprout immediately out of nothing).
It is not clear to me what is so manifestly different about a ‘simple database’ as opposed to an ‘”open database”‘ or a ‘web service’ that more or different liabilities arise in the latter ?
Hi Enrique,
Please see inline below:
> On Nov 14, 2015, at 7:43 PM, Enrique Alonso García wrote:
>
> ..
>
> Concerning this debate, it is obvious that not only these problems but many others arise when legal interoperability moves from access to data and easy and simple databases to accessing data through “open databases”, web services or e-infrastructures. When the second happens, new different issues of liability arise (or inevitably sprout immediately out of nothing).
It is not clear to me what is so manifestly different about a ‘simple database’ as opposed to an ‘”open database”‘ or a ‘web service’ that more or different liabilities arise in the latter ?
> I raised that question this summer (mid-end of July) saying that our principles had 2 gaps:
> 1) they do not distinguish between access to data, and access to software inextricably linked to the data that limits access to data if access to the software is restricted;
There is no data in this world that can be accessed without software. Even the act of reading a text file requires at least a text editor or a UNIX command Whigs is, after all, a software.
What is true is that software and data are getting intrinsically intermixed now as is the case with the use of JSON increasingly popular in web services.
Hi Enrique,
Please see inline below:
> On Nov 14, 2015, at 7:43 PM, Enrique Alonso García wrote:
>
> ..
>
> Concerning this debate, it is obvious that not only these problems but many others arise when legal interoperability moves from access to data and easy and simple databases to accessing data through “open databases”, web services or e-infrastructures. When the second happens, new different issues of liability arise (or inevitably sprout immediately out of nothing).
It is not clear to me what is so manifestly different about a ‘simple database’ as opposed to an ‘”open database”‘ or a ‘web service’ that more or different liabilities arise in the latter ?
> I raised that question this summer (mid-end of July) saying that our principles had 2 gaps:
> 1) they do not distinguish between access to data, and access to software inextricably linked to the data that limits access to data if access to the software is restricted;
There is no data in this world that can be accessed without software. Even the act of reading a text file requires at least a text editor or a UNIX command Whigs is, after all, a software.
What is true is that software and data are getting intrinsically intermixed now as is the case with the use of JSON increasingly popular in web services.
> ..
>
> The telecom of early August discarded getting into the subtleties that these aspects would imply. So now we have to live with principles on legal interoperability LIMITED to access to digital objects or for simple databases at the most.
Again, it is not clear to me what is a simple database. Is this referring to, for example, a CSV or a MS-Excel file as opposed to an Oracle or a PostGres database that are typically not file-based?
Hi Enrique,
Please see inline below:
> On Nov 14, 2015, at 7:43 PM, Enrique Alonso García wrote:
>
> ..
>
> Concerning this debate, it is obvious that not only these problems but many others arise when legal interoperability moves from access to data and easy and simple databases to accessing data through “open databases”, web services or e-infrastructures. When the second happens, new different issues of liability arise (or inevitably sprout immediately out of nothing).
It is not clear to me what is so manifestly different about a ‘simple database’ as opposed to an ‘”open database”‘ or a ‘web service’ that more or different liabilities arise in the latter ?
> I raised that question this summer (mid-end of July) saying that our principles had 2 gaps:
> 1) they do not distinguish between access to data, and access to software inextricably linked to the data that limits access to data if access to the software is restricted;
There is no data in this world that can be accessed without software. Even the act of reading a text file requires at least a text editor or a UNIX command Whigs is, after all, a software.
What is true is that software and data are getting intrinsically intermixed now as is the case with the use of JSON increasingly popular in web services.
> ..
>
> The telecom of early August discarded getting into the subtleties that these aspects would imply. So now we have to live with principles on legal interoperability LIMITED to access to digital objects or for simple databases at the most.
Again, it is not clear to me what is a simple database. Is this referring to, for example, a CSV or a MS-Excel file as opposed to an Oracle or a PostGres database that are typically not file-based?
> For me it wqs so clear that we are addressing only the very basics of data sharing (scientific publications, collections from museums… maybe collections of pictures from satellites, …)
Is this true? I am sorry but I’ve missed these discussions, but I am curious to know now if we’ve decided to only focus on scientific publications and collections from museums. Those are definitely not what I would think immediately of when thinking of “research data,” a term that is clearly in the name of our IG.
I have several scientific hats, and putting just one of them on, as a member of Plazi, we are certainly very interested in the legal interoperability of data accessed via a variety of web services. Our vision is for a data-connected world with no legal barriers to accessing, using and mixing data from different sources. I am convinced Donat will jump in here and confirm this.
Hi Enrique,
Please see inline below:
> On Nov 14, 2015, at 7:43 PM, Enrique Alonso García wrote:
>
> ..
>
> Concerning this debate, it is obvious that not only these problems but many others arise when legal interoperability moves from access to data and easy and simple databases to accessing data through “open databases”, web services or e-infrastructures. When the second happens, new different issues of liability arise (or inevitably sprout immediately out of nothing).
It is not clear to me what is so manifestly different about a ‘simple database’ as opposed to an ‘”open database”‘ or a ‘web service’ that more or different liabilities arise in the latter ?
> I raised that question this summer (mid-end of July) saying that our principles had 2 gaps:
> 1) they do not distinguish between access to data, and access to software inextricably linked to the data that limits access to data if access to the software is restricted;
There is no data in this world that can be accessed without software. Even the act of reading a text file requires at least a text editor or a UNIX command Whigs is, after all, a software.
What is true is that software and data are getting intrinsically intermixed now as is the case with the use of JSON increasingly popular in web services.
> ..
>
> The telecom of early August discarded getting into the subtleties that these aspects would imply. So now we have to live with principles on legal interoperability LIMITED to access to digital objects or for simple databases at the most.
Again, it is not clear to me what is a simple database. Is this referring to, for example, a CSV or a MS-Excel file as opposed to an Oracle or a PostGres database that are typically not file-based?
> For me it wqs so clear that we are addressing only the very basics of data sharing (scientific publications, collections from museums… maybe collections of pictures from satellites, …)
Is this true? I am sorry but I’ve missed these discussions, but I am curious to know now if we’ve decided to only focus on scientific publications and collections from museums. Those are definitely not what I would think immediately of when thinking of “research data,” a term that is clearly in the name of our IG.
I have several scientific hats, and putting just one of them on, as a member of Plazi, we are certainly very interested in the legal interoperability of data accessed via a variety of web services. Our vision is for a data-connected world with no legal barriers to accessing, using and mixing data from different sources. I am convinced Donat will jump in here and confirm this.
> “new” problems raised by open databases, web services and e-infrastructures.
Once again, it is not clear to me what are these “new” problems. The kind of problem Bernard mentioned in his original post, that of liabilities because of wrong data inserted in a database, can just as easily arise in a simple CSV file as it can in data delivered via a web service. It is just a different kind of problem from what I thought we were trying to solve.
Hi Enrique,
Please see inline below:
> On Nov 14, 2015, at 7:43 PM, Enrique Alonso García wrote:
>
> ..
>
> Concerning this debate, it is obvious that not only these problems but many others arise when legal interoperability moves from access to data and easy and simple databases to accessing data through “open databases”, web services or e-infrastructures. When the second happens, new different issues of liability arise (or inevitably sprout immediately out of nothing).
It is not clear to me what is so manifestly different about a ‘simple database’ as opposed to an ‘”open database”‘ or a ‘web service’ that more or different liabilities arise in the latter ?
> I raised that question this summer (mid-end of July) saying that our principles had 2 gaps:
> 1) they do not distinguish between access to data, and access to software inextricably linked to the data that limits access to data if access to the software is restricted;
There is no data in this world that can be accessed without software. Even the act of reading a text file requires at least a text editor or a UNIX command Whigs is, after all, a software.
What is true is that software and data are getting intrinsically intermixed now as is the case with the use of JSON increasingly popular in web services.
> ..
>
> The telecom of early August discarded getting into the subtleties that these aspects would imply. So now we have to live with principles on legal interoperability LIMITED to access to digital objects or for simple databases at the most.
Again, it is not clear to me what is a simple database. Is this referring to, for example, a CSV or a MS-Excel file as opposed to an Oracle or a PostGres database that are typically not file-based?
> For me it wqs so clear that we are addressing only the very basics of data sharing (scientific publications, collections from museums… maybe collections of pictures from satellites, …)
Is this true? I am sorry but I’ve missed these discussions, but I am curious to know now if we’ve decided to only focus on scientific publications and collections from museums. Those are definitely not what I would think immediately of when thinking of “research data,” a term that is clearly in the name of our IG.
I have several scientific hats, and putting just one of them on, as a member of Plazi, we are certainly very interested in the legal interoperability of data accessed via a variety of web services. Our vision is for a data-connected world with no legal barriers to accessing, using and mixing data from different sources. I am convinced Donat will jump in here and confirm this.
> “new” problems raised by open databases, web services and e-infrastructures.
Once again, it is not clear to me what are these “new” problems. The kind of problem Bernard mentioned in his original post, that of liabilities because of wrong data inserted in a database, can just as easily arise in a simple CSV file as it can in data delivered via a web service. It is just a different kind of problem from what I thought we were trying to solve.
> typical example: if data is georeferenced in an ESRI Arc GIS software, every individual scientist one has to spend 15,000 USD per year to access and reuse the data) as well as, in almost all open databases, when they are part of a web service and much more, an element of an e-infrastructure.
Hmm, the above is just not true universally. Data in ArcGIS can be exported, transformed, served as JSON via web services, etc. And, the issue of cost ($15k for a license) is again orthogonal to the issue of freedom. ArcGIS is indeed the very software I started my career with 30 years ago, and as a geospatial data user, this is a field I know quite a bit about.
Yes, I am very interested in such a list as the alluded to issues escape me. Please do share it with me.
Many thanks in advance,
—
Puneet Kishor
Just Another Creative Commoner
http://punkish.org/About

Discussion

[Puneet Kishor]

Possibly unnecessary errata below:
s/Whigs/which/
“a UNIX command Whigs is, after all, a software” was the auto-wronged version of “a UNIX command which is, after all, a software”

[Author]

Replies