Nepomuk Data Layout
I am happy to announce that I just finished writing an article about the data layout in Nepomuk. I think it is another must-read if you want to work with Nepomuk data, either querying it or creating data yourself. The article is another one in the series of techbase tutorials about Nepomuk. Well, this was short and fairly dry…
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=da6457d6-abc7-464d-87cb-3554e0d91769)
Always nice to hear of progress, even if it is dry ;)
Hi Sebastian,
You document a lot for developers but I have trouble finding anything relevant for the end user side. I have enabled strigi a couple times (on Kubuntu with KDE 4.2 and 4.3) but I had to disable it as it causes issues and I still don’t know what it really brings.
The nepomuk extension in krunner does not seem to do anything. I would have expected full text search given the size of indexes that Strigi produces (a couple gigs or about the same as the data indexed).
Could you write a post targeted at users? I would really appreciate that.
Anyway, just my 2 cents.
Hi Sebastian, could you please let us know what the current infrastructure (or strategy) is which deals with the fact that a user would want to share different subsets of data with different groups?
Thanks in advance, Martin.
I can imagine the following approach:
Define a subproperty of pimo:associationMember, perhaps called kde:authorizedReader, referring to a pimo:Agent. SPARQL queries could maintain these Agents at the system level, differentiating between Strigi-extracted data and user-defined data as well. Apart from user-defined authorizations, the locations where the Strigi-extracted data would come from could then be used to assign Agent authorizations.
Would an approach like this fit in with the rest of the KDE setup? If nothing in this area is decided yet and there are no similar plans (difficult to Google due to the rather generic keywords), I could further explore this and write a more detailed proposal.
I am not quite sure how you want to use the pimo:Association.
I always thought privacy management would need to work on a lower level than PIMO. After all, there might be information below the PIMO level that is private. An example would be usage statistics which are gathered automatically by some application.
The reason I mentioned pimo:Association is because PIMO is made to suit the perspective of the end-user. According to the Nepomuk Pimo Recommendation v1.1 “Every
information element encountered in knowledge work by a user is represented as a Thing”. And using the user’s perspective may also reduce their tendency to shoehorn every piece of metadata into Tags.
Thus my attempt to stick to the Pimo and Pimo-derived concepts and my current desire to use pimo:Agent and to “sub-property” pimo:Association.
Perhaps other NRL constructs can and must be used at lower levels. On the other hand, Thing-derived classes may be low-level enough to meet the mindset of the user as well as implementation requirements. For instance, a collection of usage statistics for a particular application would then also be a (singular) Thing subobject. So perhaps the restrictions on Agents can be cascaded downwards in an acceptable way by Sparql queries and complementary code.
“The locations where the Strigi-extracted data would come from could then be used to assign Agent authorizations” mentioned in my previous post is just a simple example of how the desired Agent authorization assignments can be determined in an automated way.
I will look into the issue you raised. I welcome criticism because I believe it will improve the results.
I would happily read a draft to see in a little more detail what you are thinking of. And apart from that every contribution is welcome.
Thanks for your offer. It will take some time before I have made a semi-coherent draft, but I will certainly let you know when it is ready. In the meantime I have posted a few more replies to other topics on your blog and will continue to do so.
The rough idea was to declare certain resources as public or belonging to a group. There are no details yet, though.
In the File Meta Data extracted by Strigi paragraph, the first graph is ebe343…, but the second graph with graph metadata points to e7674… .
I guess the second one should point to the first one? Then I have understood it correctly ;-)
thanks for the hint. I fixed it.