Projects/Nepomuk/ScenarioExamples: Difference between revisions
Larrsmith07 (talk | contribs) No edit summary |
(SPAM: Undo revision 51117 by Larrsmith07 (Talk)) |
||
| Line 496: | Line 496: | ||
=== Dirk searches for music that Claudia likes on his phone === | === Dirk searches for music that Claudia likes on his phone === | ||
The phone gives results from his home computer with optional access to download them. | The phone gives results from his home computer with optional access to download them. | ||
Latest revision as of 10:29, 11 May 2010
Scenario Examples
For each scenario, we find N3 data illustrating the scenario. The decisions and alternatives we have are taken into account.
Use Cases
Claudia and Berit had their wedding in Holland.
<nepomuk:/ctx/4eeefb6b-adc6-406a-a8c4-7244f14ef9c1> {
<nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66> a nco:Contact ;
nco:fullName "Claudia" ;
nco:hasIMAccount <nepomuk:/res/1424uuid321>
<nepomuk:/res/1424uuid321> a nco:IMAccount ;
nco:imAccountType "Jabber" ;
nco:imID "xmpp://[email protected]"
<nepomuk:/res/c075bca0-11f2-4df7-8969-90203bb87d18> a nco:Contact ;
nco:fullName "Berit" ;
nco:hasIMAccount <nepomuk:/res/12345>
<nepomuk:/res/12345> a nco:IMAccount ;
nco:imAccountType "Jabber" ;
nco:imID "xmpp://[email protected]"
<nepomuk:/res/790a5084-2420-41fd-aa2a-d183d3c0fd79> a nco:Contact ;
nco:fullName "Dirk" ;
nco:hasIMAccount <nepomuk:/res/44555666666>
nco:hasIMAccount <nepomuk:/res/14234123412>
<nepomuk:/res/44555666666> a nco:IMAccount ;
nco:imAccountType "Jabber" ;
nco:imID "xmpp://[email protected]"
<nepomuk:/res/14234123412> a nco:IMAccount ;
nco:imAccountType "Jabber" ;
nco:imID "xmpp://[email protected]"
}
Claudia wants to have access to Dirk's rating and other annotations.
Dirk's computer
<urn:graph1> {
<nepomuk:/res/123456789>
a nid3:ID3Audio ;
nao:lastModified "2009-08-21T09:14:37.702Z"^^xsd:dateTime ;
nie:url <file:///home/dirk/Music/Leonard Cohen/Suzanne.ogg> ;
nid3:originalTextWriter <http://www.leonardcohen.com/card#i> ;
nid3:originalAlbumTitle "Suzanne"^^xsd:string ;
nid3:composer <http://www.leonardcohen.com/card#i> ;
nao:numericRating "10"^^xsd:int ;
nao:hasTag "1960s" .
<nepomuk:/1960s>
a nao:Tag ;
nao:lastModified "2009-08-21T09:14:37.638Z"^^xsd:dateTime ;
nao:created "2009-08-21T09:14:37.54Z"^^xsd:dateTime ;
nao:identifier "1960s"^^xsd:string ;
nao:prefLabel "1960s"^^xsd:string .
}
<urn:graph2> {
<urn:graph1>
a nrl:InstanceBase ;
nao:created "2009-06-03T08:19:18.465Z"^^xsd:dateTime ;
nao:creator <nepomuk:/res/790a5084-2420-41fd-aa2a-d183d3c0fd79> .
<urn:graph2>
a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor <urn:graph1> .
}
this is what is sent (email/jabber) to claudia:
<urn:graph1> {
<nepomuk:/res/123456789>
a nid3:ID3Audio ;
nao:lastModified "2009-08-21T09:14:37.702Z"^^xsd:dateTime ;
nie:url <relfile:/Suzanne.ogg> ;
[...]
}
<urn:graph2> {...}
<urn:graph3> {
<urn:graph3> a nrl:MessageGraphMetadata .
<nepomuk:/res/790a5084-2420-41fd-aa2a-d183d3c0fd79> a nco:Contact ;
nco:hasIMAccount <nepomuk:/res/44555666666>
<nepomuk:/res/44555666666> a nco:IMAccount ;
nco:imAccountType "Jabber" ;
nco:imID "xmpp://[email protected]"
}
This is what Claudia stores in her DB
<urn:graph1> {
<nepomuk:/res/123456789>
a nid3:ID3Audio ;
nao:lastModified "2009-08-21T09:14:37.702Z"^^xsd:dateTime ;
nie:url <file:///home/claudia/Suzanne.ogg> ;
[...]
}
<urn:graph2> {...}
<urn:graph3> {
<urn:graph3> a nrl:MessageGraphMetadata .
<nepomuk:/res/790a5084-2420-41fd-aa2a-d183d3c0fd79> a nco:Contact ;
nco:hasIMAccount <nepomuk:/res/44555666666>
<nepomuk:/res/44555666666> a nco:IMAccount ;
nco:imAccountType "Jabber" ;
nco:imID "xmpp://[email protected]"
}
Important
- We add a new subclass to nrl:GraphMetadata: nrl:MessageGraphMetadata used to "mark" graphs that only contain the contact details for the nao:creators of the transferred meta data.
- Whenever a new message including a set of nrl:MessageGraphMetadata graphs is received, each of those graphs is updated, i.e. the old ones are replaced by the new ones. This automatically solves the problem of changing jabber accounts.
- If sent via email the jabber id might be replaced with an email address or another contact medium.
Dirk is not online
The system sends an email including the pictures and their metadata.
Dirk requests the wedding calendar from Claudia
# Claudia's wedding event as it is in her calendar
<nepomuk:/ctx/606282b1-cb04-11de-8a39-0800200c9a66> {
<nepomuk:/res/606282b0-cb04-11de-8a39-0800200c9a66> a ncal:Event;
nie:plainTextContent "Our wedding, everyone is invited";
nie:title "Claudia's and Berit's wedding";
ncal:dtstart <urn:uuid:9f56840d-de5b-43ba-be6f-c7d0e7097272>;
<urn:uuid:9f56840d-de5b-43ba-be6f-c7d0e7097272> ncal:dateTime "2009-11-06T12:00:00.000+01:00"^^xsd:dateTime .
ncal:dtend <urn:uuid:9f56840d-de5b-43ba-be6f-c7d0e7097273>;
<urn:uuid:9f56840d-de5b-43ba-be6f-c7d0e7097273> ncal:dateTime "2009-11-08T19:00:00.000+01:00"^^xsd:dateTime .
}
<nepomuk:/ctx/606282b1-cb04-11de-8a39-0800200c9a66-metadata> {
<nepomuk:/ctx/606282b1-cb04-11de-8a39-0800200c9a66>
a nrl:InstanceBase ;
nao:created "2009-06-03T08:19:18.465Z"^^xsd:dateTime;
nao:creator <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66>.
<urn:nepomuk:local:eb343fa9-47ec-4dae-b8d0-fb10c7b63f3d-metadata>
a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor
<urn:nepomuk:local:eb343fa9-47ec-4dae-b8d0-fb10c7b63f3d> .
}
Dirks request Dirk sends claudia a email, sms, text, jabber, whatever -
"Hey, share that wedding with me"
Claudia answers by sending him a "KDE open social whatever" answer using Jabber and/or email containing the following RDF
... exactly the same RDF as above plus the graph containing the contact information as seen above.
- Dirk includes it in his local store.
... exactly the same RDF as above.
- Dirk is looking at his calendar and wants to get updates from claudia on the event.
SELECT ?source WHERE {
GRAPH ?c {<nepomuk:/res/606282b0-cb04-11de-8a39-0800200c9a66> ?_p ?_o. }
{?c nao:creator ?source.}
}
result: claudia ?c = <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66>
call:
JABBER GET CBD AROUND <nepomuk:/res/606282b0-cb04-11de-8a39-0800200c9a66> FROM nepomuk://[email protected]/
Data is gathered on one USB stick, tagged with either embarrassing or childhood
- Dirk has both embarrassing and childhood pictures
- of Claudia and of Berit on his desktop.
- The childhood pictures he got from her parents via email.
- The tutu picture he took on a project meeting.
<nepomuk:/ctx/606282b5-cb04-11de-8a39-0800200c9a66> {
<file:///home/dirk/pictures/embarassingClaudia.jpg> a nexif:Photo;
nie:title "Claudia Drunk in Tutu on Beach";
nao:tag <nepomuk:/res/606282b6-cb04-11de-8a39-0800200c9a66>;
nao:numericalRating "9".
<file:///home/dirk/pictures/claudia_in_bathtub.jpg> a nexif:Photo;
nie:title "Claudia as baby in bathtub";
nao:tag <nepomuk:/res/606282b7-cb04-11de-8a39-0800200c9a66>;
nao:numericalRating "5".
<nepomuk:/res/606282b6-cb04-11de-8a39-0800200c9a66> a nao:Tag;
rdfs:label "Embarrassing".
}
<nepomuk:/ctx/606282b5-cb04-11de-8a39-0800200c9a66-metadata> {
<nepomuk:/ctx/606282b1-cb04-11de-8a39-0800200c9a66>
a nrl:InstanceBase ;
nao:created "2009-06-03T08:19:18.465Z"^^xsd:dateTime;
nao:creator <DIRK-UUID>.
<nepomuk:/ctx/606282b5-cb04-11de-8a39-0800200c9a66-metadata>
a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor
<nepomuk:/ctx/606282b1-cb04-11de-8a39-0800200c9a66> .
}
<nepomuk:/ctx/606282b8-cb04-11de-8a39-0800200c9a66> {
<nepomuk:/res/606282b7-cb04-11de-8a39-0800200c9a66> a nao:Tag;
rdfs:label "Childhood".
}
<nepomuk:/ctx/606282b8-cb04-11de-8a39-0800200c9a66-metadata> {
<nepomuk:/ctx/606282b8-cb04-11de-8a39-0800200c9a66>
a nrl:InstanceBase ;
nao:created "2009-06-03T08:19:18.465Z"^^xsd:dateTime;
nao:creator <DIRK-UUID>.
<nepomuk:/ctx/606282b8-cb04-11de-8a39-0800200c9a66-metadata>
a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor
<nepomuk:/ctx/606282b8-cb04-11de-8a39-0800200c9a66> .
}
Ok, now Dirk uses Dolphin and nepomuksearch to find "embarrassing" and "childhood" pictures of Claudia. He copy/pastes the files to the USB stick. lib nepomuk recognizes this copy/paste operation, sees at the mountpoint that it is USB and removable, sees that the filesystem is FAT32. We didn't decide yet how to store the RDF on the USB stick, I assume it ends up in some file somewhere on the stick.
- on the usb stick.
- we assume the foldernames relative to the root of the stick.
- Leo decides for this case: screw contexts: to keep it as simple as possible we don't use metadata graph uris here just to simplify things.
- When a user wants to import this into his central soprano store, she can easily check for each fact if it was in the store before and NOT add it if it was.
{
<fools:embarassingClaudia.jpg> a nexif:Photo; nie:title "Claudia Drunk in Tutu on Beach"; nao:tag <nepomuk:/res/606282b6-cb04-11de-8a39-0800200c9a66>; nao:numericalRating "9". <fools:claudia_in_bathtub.jpg> a nexif:Photo; nie:title "Claudia as baby in bathtub"; nao:tag <nepomuk:/res/606282b7-cb04-11de-8a39-0800200c9a66>; nao:numericalRating "5". <nepomuk:/res/606282b6-cb04-11de-8a39-0800200c9a66> a nao:Tag; rdfs:label "Embarrassing". <nepomuk:/res/606282b7-cb04-11de-8a39-0800200c9a66> a nao:Tag; rdfs:label "Childhood".
}
There are several decisions here, which may overlap with other scenarios. Maybe we should move these questions on a separate wikipage and reference this from here.
- how to reference the files on the usb stick? The file-uri standard only talks of hostnames, not of devices or device-ids, which a usb stick has.
- use a new protocol fools:embarassingClaudia.jpg which is relative to the root of the stick of relative to the metadata file
- break the file protocol file:removable:/embarassingClaudia.jpg
- Use a nepomuk:/ URI for the file resource; Store the relative URL to the file in nfo:filePath (new property);
- on VFAT, what is the filename for our metadata files?
- use MacOSX resource forks and their ._filename approach. Conform to their binary streaming format, adding a new fork for RDF
- use our own extension/file naming scheme for each file. ._filename.rdf screw MacOSX, lets just use Turtle with named graphs here (trig).
- the annotations are, once exported, redundant on the stick. A tag can be exported multiple times, where to store the tag? Where to store the data about one file?
- provide a central index.rdf file which contains all metadata of a folder
- provide a central index.rdf for metadata for tags, etc. use ._embarassingClaudia.jpg for individual files
- save all metadata redundantly in each file-metadata needing it. use ._embarassingClaudia.jpg to store the RDF of individual files. redundantly store all tags, contacts, etc, which are referenced from a file, into the metadata file of this file.
- Assuming the user exported the data to the stick and plugs the stick into his own computer again. The central index should not go crazy now importing the user's own annotations.
- store the annotations on the usb stick in a way that is a bijective, lossless, representation of the metadata in the soprano RDF store. adding it again would not change one bit in the triplestore.
- mark the annotations in the stick in a way that says "do not import when on computer Y of user X"
- do not add the metadata to the central index. do not search on them. people should copy the files to their local filesystem.
- do not add the metadata to the central index. instead, store a binary index format (ahem, this won't work so easy) on the stick that allows super-fast querying and use that in any query to the soprano service. soprano mounts the auxiliary index from the disk when the usb stick mounts and demounts it when the stick goes away.
- do not add the metadata to the central index. instead, quickly index the whole stick and keep an index for the stick in-memory. soprano mounts the auxiliary index from the disk into memory when the usb stick mounts and demounts it when the stick goes away.
The whole wedding folder is archived on DVD including the metadata
One year later the data should still be accessible.
Source in uri:
<nepomuk:/ctx/13577>
{
<nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66> a nco:Contact
; nco::fullName "Claudia"
. <nepomuk:/res/e8a68b30-cb04-11de-8a39-0800200c9a66> a nepo:Image
; nepo:file "/wedding/picture1.jpg"
; nao:hasTag [ a nao:Tag ; nao:prefLabel "embarrassing" ]
, [ a nao:Tag ; nao:prefLabel "berit" ]
, [ a nao:Tag ; nao:prefLabel "claudia" ]
; nao:creator <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66>
. <nepomuk:/res/34c4c7c1-cb05-11de-8a39-0800200c9a66> a nepo:Image
; nepo:file "/wedding/picture2.jpg"
; nao:hasTag [ a nao:Tag ; nao:prefLabel "young" ]
; nao:creator <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66>
}
Fulfills req
Source as nepo:hasSource:
<nepomuk:/ctx/13577>
{
<urn:uuid:4c4c7c8-cb05-11de-8a39-0800200c9a66> a nco:Contact
; nco::fullName "Claudia"
; nepo:hasSource <xmpp://[email protected]/>
. <urn:uuid:e8a68b30-cb04-11de-8a39-0800200c9a66> a nepo:Image
; nepo:file "/wedding/picture1.jpg"
; nepo:hasSource <xmpp://[email protected]/>
; nao:hasTag [ a nao:Tag ; nao:prefLabel "embarrassing" ]
, [ a nao:Tag ; nao:prefLabel "berit" ]
, [ a nao:Tag ; nao:prefLabel "claudia" ]
; nao:creator <urn:uuid:4c4c7c8-cb05-11de-8a39-0800200c9a66>
. <urn:uuid:34c4c7c1-cb05-11de-8a39-0800200c9a66> a nepo:Image
; nepo:file "/wedding/picture2.jpg"
; nepo:hasSource <xmpp://[email protected]/>
; nao:hasTag [ a nao:Tag ; nao:prefLabel "young" ]
; nao:creator <urn:uuid:4c4c7c8-cb05-11de-8a39-0800200c9a66>
}
Fulfills req
Source in graphs:
<nepomuk://[email protected]/ctx/6121>
{
<urn:uuid:34c4c7c8-cb05-11de-8a39-0800200c9a66> a nco:Contact
; nco::fullName "Claudia"
; nepo:hasSource <xmpp://[email protected]/>
}
<nepomuk://[email protected]/ctx/09851>
{
<urn:uuid:e8a68b30-cb04-11de-8a39-0800200c9a66> a nepo:Image
; nepo:file "/wedding/picture1.jpg"
; nao:hasTag [ a nao:Tag ; nao:prefLabel "embarrassing" ]
, [ a nao:Tag ; nao:prefLabel "berit" ]
, [ a nao:Tag ; nao:prefLabel "claudia" ]
; nao:creator <urn:uuid:4c4c7c8-cb05-11de-8a39-0800200c9a66>
}
<nepomuk://[email protected]/ctx/5513>
{
<urn:uuid:34c4c7c1-cb05-11de-8a39-0800200c9a66> a nepo:Image
; nepo:file "/wedding/picture2.jpg"
; nao:hasTag [ a nao:Tag ; nao:prefLabel "young" ]
; nao:creator <urn:uuid:4c4c7c8-cb05-11de-8a39-0800200c9a66>
}
Claudia gets a lot of pictures from people, tagged with creators and people on the pictures
Now Claudia wants to find all pictures that depict herself and Berit.
Use example data in previous section.
SELECT ?picture FROM * WHERE { ?picture a nepo:Image ; nao:hasTag [ nao:prefLabel "berit", "claudia" ] }
Works for all three cases
<nepomuk:/ctx/08933dfb-cd33-498d-84c1-2db1d83e5af4> {
<nepomuk:/res/edf808e5-9036-4292-90b4-d90e975ac117>
a xesam:File ;
a nfo:FileDataObject ;
nao:lastModified "2009-08-26T10:53:38.966Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
nie:plainTextContent "asdf123"^^<http://www.w3.org/2001/XMLSchema#string> ;
xesam:url "/home/claudia/networkkey.txt"^^<http://www.w3.org/2001/XMLSchema#string> ;
xesam:fileExtension "txt"^^<http://www.w3.org/2001/XMLSchema#string> ;
nie:isPartOf <file:///home/claudia> ;
nie:contentSize "7"^^<http://www.w3.org/2001/XMLSchema#unsignedInt> ;
nie:url <file:///home/claudia/networkkey.txt> ;
nao:created "2009-08-26T10:53:38.516Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
}
<nepomuk:/ctx/08933dfb-cd33-498d-84c1-2db1d83e5af4-metadata> {
<nepomuk:/ctx/08933dfb-cd33-498d-84c1-2db1d83e5af4> a nrl:InstanceBase> ;
nao:created "2009-11-06T17:26:55.223Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
nao:creator <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66> ;
strigi:indexGraphFor <nepomuk:/res/edf808e5-9036-4292-90b4-d90e975ac117> .
<nepomuk:/ctx/08933dfb-cd33-498d-84c1-2db1d83e5af4-metadata> a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor <nepomuk:/graph/08933dfb-cd33-498d-84c1-2db1d83e5af4> .
}
Dirk gets a set of music files by Claudia
Claudia has rated and tagged the files. Dirk integrates the files into his own system and changes tags and ratings. Later he needs to determine which music Claudia likes because he will act as the DJ at her wedding.
<nepomuk:/ctx/14fc3d4b-c150-4e57-991c-b876b26248d4> {
<nepomuk:/res/04f64db3-f4b8-4d09-a537-bcd143fab70c> a nfo:FileDataObject ;
a nmmMusicPiece ;
nco:creator <nepomuk:/res/Mika> ;
nie:title "Grace Kelly"^^<http://www.w3.org/2001/XMLSchema#string> ;
xesam:fileExtension "mp3"^^<http://www.w3.org/2001/XMLSchema#string> ;
nie:mimeType "audio/mpeg"^^<http://www.w3.org/2001/XMLSchema#string> ;
nie:url <file:///home/claudia/Music/Mika.mp3> ;
nfo:fileName "Mika.mp3"^^<http://www.w3.org/2001/XMLSchema#string> ;
nao:rating "9" ;
nao:hasTag <nepomuk:/res/nice> ;
nao:hasTag <nepomuk:/res/love> .
}
<nepomuk:/ctx/14fc3d4b-c150-4e57-991c-b876b26248d4-metadata> {
<nepomuk:/ctx/14fc3d4b-c150-4e57-991c-b876b26248d4> a nrl:InstanceBase> ;
nao:created "2009-11-06T17:26:55.223Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
nao:creator <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66> ;
strigi:indexGraphFor <nepomuk:/ctx/14fc3d4b-c150-4e57-991c-b876b26248d4> .
<nepomuk:/ctx/14fc3d4b-c150-4e57-991c-b876b26248d4-metadata> a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor <nepomuk:/ctx/14fc3d4b-c150-4e57-991c-b876b26248d4> .
}
<nepomuk:/ctx/c3703e3b-d0dc-4c1c-a2f4-11e4aa081723> {
<nepomuk:/res/04f64db3-f4b8-4d09-a537-bcd143fab70c> nao:hasTag <nepomuk:/res/toplayatwedding> ;
nao:rating "6" .
}
<nepomuk:/ctx/c3703e3b-d0dc-4c1c-a2f4-11e4aa081723-metadata> {
<nepomuk:/ctx/c3703e3b-d0dc-4c1c-a2f4-11e4aa081723> a nrl:InstanceBase> ;
nao:created "2009-11-06T17:26:55.223Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
nao:creator <nepomuk:/res/790a5084-2420-41fd-aa2a-d183d3c0fd79> ;
strigi:indexGraphFor <nepomuk:/ctx/c3703e3b-d0dc-4c1c-a2f4-11e4aa081723> .
<nepomuk:/ctx/c3703e3b-d0dc-4c1c-a2f4-11e4aa081723-metadata> a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor <nepomuk:/ctx/c3703e3b-d0dc-4c1c-a2f4-11e4aa081723> .
}
Dirk will run a SPARQL query like the one below, to get the songs rated >= 8 by Claudia.
select ?song
where {
{ ?song a nmm:MusicPiece }
graph ?g { ?song nao:rating ?rating . FILTER xsd:int(?rating) >= "8"^^xsd:int }
{ ?g nao:creator <nepomuk:/res/34c4c7c8-cb05-11de-8a39-0800200c9a66> }
}
Dirk wants to exclude his comments about Claudia's ugly dress from the pictures he sends her
Example data
Current state of data in KDE4:
<urn:A> {
<file:///home/foobar/someimage.jpg>
a nfo:Image ;
nao:desciption "Ugly!" .
}
<urn:B> {
<urn:B> a nrl:GraphMetadata .
<urn:A> a nrl:IntanceBase ;
nao:created "2009-11-05T...."^^xsd:dateTime .
}
<urn:C> {
<file:///home/foobar/someimage.jpg>
nao:rating 5 .
}
<urn:D> {
<urn:D> a nrl:GraphMetadata .
<urn:C> a nrl:IntanceBase ;
nao:created "2009-11-06T...."^^xsd:dateTime .
}
Todo
To exclude one property we would need privacy settings on the property level. This would mean storing each property in its own graph which is not done in KDE at the moment (but would be easy to achieve).
Then we could easily mark the nao:description as non-public.
Claudia's brother has downloaded a lot of the music Claudia gave to Dirk
He needs the music files to be untraceable to him. However he still wants ratings and tags to be preserved.
After changing his jabber ID Dirk still wants to be able to access all his archived data
Dirk has two jabber IDs (SAP for work stuff and Jabber.org for private stuff)
He wants to share work information using his SAP ID and wedding pictures using his personal ID.
Dirk downloads a wedding picture from Claudia's picture page including all comments
The information about who wrote which comment is preserved.
Dirk starts writing a presentation about Claudia's youth and invites Claudia's brother to write it collaboratively on his computer
Dirk syncs the wedding photos with his mobile and tags them on the plane
When he comes home he syncs his phone again and the tags are synced, too.
Dirk searches for music that Claudia likes on his phone
The phone gives results from his home computer with optional access to download them.