I've created a new page in the "Overview" section to start collecting
and formalizing some DP definitions. It's becoming clear in the
discussions and recent press that there's a need to remove some
ambiguity around some concepts.
To that end, please contribute definitions to concepts and terms to
this page. I'll commit myself to shepherding the page, as long as
everyone can contribute terms as they bump into them.
Thanks for setting up the definitions page.
One of the most fundamental definitions of that of portable data. It
currently reads: "DATA rendered in a common open format and accessible
by a system other than that which is rendering it." This refers, I
think, to interoperability via standards, rather than to portability.
The key point is not that data can be moved, but that you don't need
to move it to a different system in order to use it.
I make a similar point, at a rather more general level, elsewhere:
http://changingway.org/2008/01/11/data-portability-worthy-aim-mislead... Andrew
+1 for your comment. I agree with this. Linked Data is the more interesting problem, and should furthermore be less of an issue for the current players in the field. I want to be able to link from my foaf file to people across social networks. LinkedIn and facebook will continue to provide great interfaces and good maintanance services for that data all the better.
Of course I would like to be able to "port" that data into my local address book too so that it can be used with the other applications on my computer, such as mail, etc. But that is just a result of having machine readable data to begin with.
> Thanks for setting up the definitions page. > One of the most fundamental definitions of that of portable data. It > currently reads: "DATA rendered in a common open format and accessible > by a system other than that which is rendering it." This refers, I > think, to interoperability via standards, rather than to portability. > The key point is not that data can be moved, but that you don't need > to move it to a different system in order to use it. > I make a similar point, at a rather more general level, elsewhere: > http://changingway.org/2008/01/11/data-portability-worthy-aim-mislead... > Andrew
> +1 for your comment. I agree with this. Linked Data is the more > interesting problem, and should furthermore be less of an issue for > the current players in the field. I want to be able to link from my > foaf file to people across social networks. LinkedIn and facebook will > continue to provide great interfaces and good maintanance services for > that data all the better.
+1 for you Henry. This is a good distinction you have made between moving my data from a system to another (this could be something I would like to do, but not necessary, as you described above); and wanting to link one data source I produced, to another one I produced, or some stuff another guy created on another service (endpoint), etc.
This is the difference between importing and exporting data, and *linking data* (in distinction of linking web pages).
Since someone opened the door, I would suggest you to take a look at the emerging principle of *linked data* on the semantic web:
> > +1 for your comment. I agree with this. Linked Data is the more
> > interesting problem, and should furthermore be less of an issue for
> > the current players in the field. I want to be able to link from my
> > foaf file to people across social networks. LinkedIn and facebook will
> > continue to provide great interfaces and good maintanance services for
> > that data all the better.
> +1 for you Henry. This is a good distinction you have made between
> moving my data from a system to another (this could be something I would
> like to do, but not necessary, as you described above); and wanting to
> link one data source I produced, to another one I produced, or some
> stuff another guy created on another service (endpoint), etc.
> This is the difference between importing and exporting data, and
> *linking data* (in distinction of linking web pages).
> Since someone opened the door, I would suggest you to take a look at the
> emerging principle of *linked data* on the semantic web:
> From this Wikipedia page you will find some references to other web
> pages, tutorials, papers and services explaining what linked data is.
> Basically it is what Henry described above, using semantic web
> technologies and principles (rdf + others).
> Good reading.
> Take care,
Great contributions that will hopefully clarify the definitions. As I
am sure you can both see (hopefully others too), we are talking about
many important data access themes under a single data portability
heading:
1. Data Mobility (moving data from distinct locations via Import and
Export using agreed data formats)
2. Data Referencing
I think most Data Portability folks currently think about 1.
Hopefully, the evolution of this thread should expose the importance
of point 2.
> Great contributions that will hopefully clarify the definitions. As I > am sure you can both see (hopefully others too), we are talking about > many important data access themes under a single data portability > heading:
> 1. Data Mobility (moving data from distinct locations via Import and > Export using agreed data formats) > 2. Data Referencing
Exactly, so from 2 (referencing data) you can perform 1 (moving data). But you have no obligation to do 1. As Henry carefully pointed out: services from yahoo, google or whatever deal wonderfully with many users data: both with the user interface and the data managing system that take care of the availability of the data, its backuping, etc. In my opinion, this add value to users, and what add value to users worth something (money). So, we slowly fallback to services (web services) to createvalue, and not the data itself (at least for this specific discussion).
However, I would refers as 1 for data referencing, so:
1. Data Referencing
2. Data Mobility (moving data from distinct locations via Import and Export using agreed data formats)
So, from linked data you can perform data mobility.
> 1. Data Referencing > 2. Data Mobility (moving data from distinct locations via Import and > Export using agreed data formats)
But I think I would like to put some things in context. What this means in terms of semantic web concepts and technologies?
This discussion will be articulated in one context: the Web. So all the discussion here will take into consideration that all data is available on the Web, so with Web technologies (this could be extended to other networks, with other protocols and technologies, but it won't be the case here).
So, how #1 is handled on the semantic web? Well, much data is available about that question on the wikipedia page I sent in one of my earlier mail in that thread. Basically it is about referencing data using URIs, and these URIs should ideally be "dereferencable" on the Web. What this mean? This mean that if I have a user account on a certain web service, and that I have one URI that define that account, and that this URI is in fact a URL, so that I can get data by looking at this URL on the Web (in this case we say that the URI is dereferencable on the web).
This mean one wonderful thing: if I get a reference (URI) to something, this means that in the best of the cases, I can also get data describing this thing by looking on the Web for it. So, instead of getting a HTML page describing that thing (this can be the case, but is not limited to) I can get the RDF description of that thing too ( via web server content negotiation). This RDF description can be use by any web service, any software agent, or whatever, to help me with some tasks (importing/exporting my personal data? Merging two agenda in the same calandar? Planning my next trips? and so on).
Now that I can easily reference and access any data, how the data exchange is done to make it mobile? Well, the semantic web answer for this is: RDF+Ontologies.
RDF is a way to describe things called "resources". These resources can be anything: people, books, etc. There is a mechanism that let one describing things according to their properties (predicates). The result is a graph of relationships describing a resource and potentially to relate this resource to other resources (think about a social graph).
However, RDF can't be used alone. In order to make this thing effective, one need to use "vocabularies", called ontologies, to describe a resource and its properties. These ontologies can be seen as a controlled vocabulary defined by a community of experts to describe some domains of things (books, music, people, networks, calendar, etc). It is much more than a controlled vocabulary, but it is easier to understand what it is that way.
FOAF is one of these vocabulary. You can use this ontology to describe a person, and its relation with other people, in RDF. So, you will say: this resources is named Fred, Fred lives near Quebec City, and Fred knows Kingsley. And so on.
By using RDF + Ontologies, the data is easily made Mobile. By using such standards, systems will be able to read, understand and manage data coming from multiple different systems. But you know what is the beauty with RDF? It is that if one of the system doesn't know one vocabulary, or do not understand all classes and properties of a vocabulary used to describe a resource, it will only ignore that data and concentrate its efforts on the things it understands. It is like if I would speak to you, in the same conversation, in French, English, Italian and Chinese. You would only understand what I say in the languages you know and act upon it. You will only discard the things you don't understand.
Well, it is really hard to write about all these things in a single email, I missed many things that are wonderful about that, but I will extend my thoughts over time on the ML, I think it is the best way for everybody that are not used to these concepts: step by step.
But for them that are interested in all these possibilities, I would suggest you to do some research on the web about these topics, because there is a lot of stuff that beatifully explain all these things (and that are by far better written than this email).
Hope this put some lights on these concepts and possibilities,
Kinglsey - I disagree that DP is mainly about point 1 right now. I
agree the name 'DataPortability' sounds like data is being moved, but
I think that it can just as easily be 're-purposed' as well. You will
notice that http://www.dataaccessibility.com/ also points to
dataportability.org ;)
If you look at the blueprint also it is very much about referencing/
pointing to data - there is no need to move it around unless you stop
trusting the vendor or you are backing up.
Chris
On Jan 14, 3:36 am, kidehen <kide...@openlinksw.com> wrote:
> On Jan 13, 10:01 am, Frederick Giasson <f...@fgiasson.com> wrote:
> > +1 too.
> > > +1 for your comment. I agree with this. Linked Data is the more
> > > interesting problem, and should furthermore be less of an issue for
> > > the current players in the field. I want to be able to link from my
> > > foaf file to people across social networks. LinkedIn and facebook will
> > > continue to provide great interfaces and good maintanance services for
> > > that data all the better.
> > +1 for you Henry. This is a good distinction you have made between
> > moving my data from a system to another (this could be something I would
> > like to do, but not necessary, as you described above); and wanting to
> > link one data source I produced, to another one I produced, or some
> > stuff another guy created on another service (endpoint), etc.
> > This is the difference between importing and exporting data, and
> > *linking data* (in distinction of linking web pages).
> > Since someone opened the door, I would suggest you to take a look at the
> > emerging principle of *linked data* on the semantic web:
> > From this Wikipedia page you will find some references to other web
> > pages, tutorials, papers and services explaining what linked data is.
> > Basically it is what Henry described above, using semantic web
> > technologies and principles (rdf + others).
> > Good reading.
> > Take care,
> Great contributions that will hopefully clarify the definitions. As I
> am sure you can both see (hopefully others too), we are talking about
> many important data access themes under a single data portability
> heading:
> 1. Data Mobility (moving data from distinct locations via Import and
> Export using agreed data formats)
> 2. Data Referencing
> I think most Data Portability folks currently think about 1.
> Hopefully, the evolution of this thread should expose the importance
> of point 2.
> Kinglsey - I disagree that DP is mainly about point 1 right now. I > agree the name 'DataPortability' sounds like data is being moved, but > I think that it can just as easily be 're-purposed' as well. You will > notice that http://www.dataaccessibility.com/ also points to > dataportability.org ;)
Nice
> If you look at the blueprint also it is very much about referencing/ > pointing to data - there is no need to move it around unless you stop > trusting the vendor or you are backing up.
Well, this is just not about that. It could also be about importing data to enhance my local calendar with data I created elsewhere, synching some planned, tripes, etc. o, much of the time, I think we will reference, but other time, a system, a person, whatever, will need to check, import and act upon that data. It is where "moving" the data could make sense.
On Jan 13, 6:30 pm, Chris Saad <chris.s...@gmail.com> wrote:
> Kinglsey - I disagree that DP is mainly about point 1 right now. I
> agree the name 'DataPortability' sounds like data is being moved, but
> I think that it can just as easily be 're-purposed' as well. You will
> notice thathttp://www.dataaccessibility.com/also points to
> dataportability.org ;)
> If you look at the blueprint also it is very much about referencing/
> pointing to data - there is no need to move it around unless you stop
> trusting the vendor or you are backing up.
> Chris
Chris,
Open Data Access (Referencing) combined with Standard Data
Representation formats deliver Data Portability. Simply Redirecting
<http://www.dataaccessibility.com> to <http://dataportability.org> is
not necessarily the clear route of expression.
Why doesn't the Data Portability page explicitly identify the: Open
Data Access and Standard Data Formats sub components?
Linked Data ultimately exposes the Open Data Access part of the story
(think ODBC or JDBC for the Distributed Web Database / Data Web).
