I submitted a short proposal to speak at LIFT-Austria and got my acceptence mail!
See you there on March 18–20 in Vienna, its going to be interesting. My talk will be about something around “tools for thinking – how semantic personal information management is going to change our way of thinking”
Looking forward to the event and to meet others in the field, and to drink a beer. If you are also going, ping me.
Here are my thoughts on what problems and solutions we have:
Leobard’s thoughts about needed changes to RDF.
1) Reification is not an aesthetically appealing model because it forces the triple/statement structure on quads. Therefore it is not used much and discouraged by some “named graph” enthousiasts. Nevertheless, the need to identify and annotate single triples and their values is there.
2) rdf:value, datatype, language, and reification all address the same need and are redundant.
3) The relation between a web resource (i.e. a web page in html) and the RDF document (named graph) containing the RDF data of the web page can NOT be expressed with the RDF standard. There exist various, scarcely documented methods such as the HTML Header tag “” or 303 redirects, or content negotiation. Some of these methods are described in “Cool Uris for the Semantic Web”). This has been causing personal bellyaches for me since editing “Cool Uris for the Semantic Web”. It is not aesthetic as this central feature of linked data and RDF can’t be represented in RDF.
4) Statements about reified triples must be possible for sets of triples.
Suggestions for Solutions: [syntax: problem->solution]
1)->S1) On the core level of RDF, add an URI identifier to a triple. Let Serializations allow to add this URI to the triple. Add a triple identifier to the core of the spec and APIs.
2)->S2) Deprecate rdf:value.
3)->S3) In RDFS we already hint at HTTP dereferenciation and linked data in rdfs:seeAlso and its subproperty rdfs:isDefinedBy. In foaf we have foaf:homepage that links a resource to its web page. In SKOS we had skos:isSubjectOf (but it was removed) I propose “”” rdfs:describes a rdfs:Property; rdfs:domain rdfs:Resource; rdfs:range rdfs:Resource; rdfs:comment “The subject RDF resource is metadata for the object document.” “”” . This solution seems to add problems though, as the relation between document and resource is dynamic and ever changing.
3)->S3.1) Leave it as is. The problem of linking between HTML and RDF representations is on the level of HTML and not on RDF.
Mark has now received a letter via registered mail from the City of Mannheim, which says that he must sign the letter and give up the Twitter account, or suffer the full force of a city’s legal team as they try to drag our a**es through the courts.
In my opinion, the city of Mannheim can fuck off. If they forget to register their own name on twitter, they are clearly years behind. And they will always be too late in all the good services, so if they start doing this with Twitter, where will it end? The german legislation allows you to sue for DOMAIN names, which is kind-of-ok, but with web 2.0 accounts? Anyway, I am with the small David here against Goliath.
In the NEPOMUK EU project, we have created standards and implementations for the semantic desktop. Based on which assumptions?
To get an understanding what people do at various companies and what support they need, a set of personas was created. Based on interviews with real people, a persona is a fictitious person that represents a user group.
Here is Claudia, she and her colleague Dirk were the two most popular personas within our project group:
The personas helped us to think about what the software must do for the users, demo the software, create prototypes, and create test data for unit testing. As they helped us, maybe they can also help you, so I asked around in the consortium if we could publish them, and we could, so here they are:
NEPOMUK testdata (this was public before, both is related, so having the link here will help you)
A definition was given by the authors from the Human Computer Interaction Group at KTH:
A persona is a fictitious person that represents a user group. They are based on users studies on real people.
Personas are a detailed description and a visualisation of the users. They have a life, goals and scenarios where they fulfill their goal. They help us to focus on the users during the design and give all stakeholders in the project a clear picture of the users’ needs and requirements. Everyone in the project has the same view of the users and personas are also a constant reminder of the users.
When personas are used in the design work and they make it easier to design for them. They “depersonalise” discussions on functionality and allow the designers to focus on designing for the personas.
p.s. The personas were so good, we continued using them at the NEPOMUK KDE Workshop. There, the story continues with news on Claudia’s private life. In fact, she is having a wedding with her long-term friend Berit in Holland! Read the fascinating news and N3 files yourself…