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.
Henry
> +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:
http://en.wikipedia.org/wiki/Linked_Data
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,
Fred
> 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.
Take care,
Fred
> 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,
Take care,
Fred
> 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.
Take care,
Fred