Hi,<div><br></div><div>I'm develop a couple of month ago a python script to share and backup nepomuk data in usb harddisks and is available here:</div><div><br></div><div><a href="http://kde-apps.org/content/show.php/Neposidekick+service+menu?content=137233" target="_blank">http://kde-apps.org/content/show.php/Neposidekick+service+menu?content=137233</a></div>
<div><br></div><div>Sadly I currently have no free time to continue with the develop neither learning sparql and virtuoso so I stop development but I'm using frequently to share my tags, comments and score in different systems and users.</div>
<div><br></div><div>I don't know if this would be useful to you but I store all data in a hidden text file named .nepomuksidekick per directory and I really satisfied with results. I have two different file formats, one full with all available data included (probably with some bugs :)) and the other is human readable so its easy to understand and editable by humans and with limited data support. Both are csv text files because this format is really easy to read and write :).</div>
<div><br></div><div>All is done with a subclass of Nepomuk.Resource and two main methods, toText() and fromText(). </div><div><br></div><div>If you think that work would be useful to you I can send you the last version and share knowledge with you.</div>
<div><br></div><div>Bye</div><div>Ignacio</div><div><br><div class="gmail_quote">On Thu, May 5, 2011 at 10:18 PM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org" target="_blank">trueg@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 05/04/2011 04:52 PM, Bruce Adams wrote:<br>
>> On 05/03/2011 07:24 PM, Bruce Adams wrote:<br>
>>> That roughly accords with my originally intentions anyway.<br>
>>> I was thinking in terms of a standalone tool, library & api<br>
>>> for managing simple meta data (just tags)<br>
>><br>
>> IMHO it does not make sense to start with tags alone. I think it would<br>
>> be much simpler to only start with literal properties, i.e. those for<br>
>> which there is no need to store additional resources.<br>
>> Then the next step would be to also store the additional resources which<br>
>> gets much more complicated as it also involves garbage collection when<br>
>> the user removes a property.<br>
>><br>
> I am coming from a non-nepomuk background with different but overlapping goals.<br>
> I agree about starting with literal properties.<br>
> I think of tags as being the simplest property possible. You are implying tags<br>
> are not this simple.<br>
<br>
</div>Well, tags are not literal props in Nepomuk but separate resources.<br>
Thus, I referred to literals.<br>
<div><br>
> I think in nepomuk they are associated with an ontology that knows the set of<br>
> all possible tags.<br>
> This is a more feature rich representation but also a more complex one.<br>
> I guess we'll see how the code grows.<br>
> The 15 basic elements of the dublin core would be another good set to start<br>
> with.<br>
<br>
</div>Not really as dublin core is not used in Nepomuk. I still think that<br>
simply saving all literal values is a good idea. I see no point in<br>
restricting yourself to a specific set of properties or one ontology.<br>
Just get all literals. This could either be done with a SPARQL query<br>
(FILTER(isliteral(?v)) or by simply listing all properties and ignoring<br>
those that have a resource type:<br>
<br>
Nepomuk::Resource res(url);<br>
QHash<QUrl, Nepomuk::Variant> props = res.properties();<br>
for each prop in props:<br>
if(value.isResource() || value.isResourceList())<br>
continue;<br>
<br>
something like that.<br>
<div><br>
><br>
>>> and later growing this to support integration with nepomuk.<br>
>>> and incorporate other kinds of metadata.<br>
>>><br>
>>> I'm happy to hear suggestions.<br>
>>><br>
>>> There are two main design choices to consider.<br>
>>> 1. the location of the metadata<br>
>>> one per file<br>
>>> one metadata area per directory<br>
>>> one per filesystem<br>
>><br>
>> IMHO there should be one file per file system. The reason is simple:<br>
>> that way we only need to store additional resources like the previously<br>
>> mentioned project once. If we had one file per dir or file than we would<br>
>> have to store (and later merge) these additional resources over and over.<br>
>><br>
> Merging is an inevitable requirement when you copy data around.<br>
> You can't necessarily have one file per file system if that file system is<br>
> multi-user.<br>
> It may be sufficient for a USB flashdrive but not when you have say<br>
> /home/user1<br>
> /home/user2<br>
<br>
</div>But IMHO this is not a use-case.<br>
<div><br>
><br>
> It brings in all the complexity of multi-users and security.<br>
> So I think the best thing is to be flexible.<br>
> So if you have an acessible metadata directory at the root of the filesystem<br>
> you need no other but if not try the next level down<br>
> (or rather start at the file and work up the tree until you find one).<br>
<br>
</div>Sure, if it can be designed flexible enough to support both - great. :)<br>
<div><div></div><div><br>
>>> on balance I believe per directory makes most sense.<br>
>>> Though it is not that much extra complication to say a metadata area is not<br>
>>> required for a sub-directory of a directory which already has one and this<br>
>> would<br>
>>> keep the meta-data layout simple.<br>
>>><br>
>>> 2. the format of the metadata<br>
>>> binary or text<br>
>>> if text, trig, turle , trix or something else.<br>
>><br>
>> As I already mentioned I would prefer trig since that allows us to store<br>
>> graph metadata which contains information like "when was the data<br>
>> created" and "who created the data".<br>
>><br>
>> One could compress this file. Sadly there is no pseudo-standard for RDF<br>
>> storage yet as there is for SQL (sqlite) so using redland seems weird to me.<br>
>><br>
> I'll look into it<br>
><br>
>>> there is an advantage to the simplicity of <key>=<value> for just tags<br>
>>> but it will not scale well to complex meta data.<br>
>>> for binary I would imagine a standard database such as sqlite.<br>
>>> The advantage there is compactness.<br>
>>><br>
>>> There is nothing to stop either of these being configurable but it is<br>
>> sensible<br>
>><br>
>>> to<br>
>>> start as you mean to go in.<br>
>>><br>
>>> I think metadata should live in a .metadata directory except that .metadata<br>
>> is<br>
>><br>
>>> used by eclipse.<br>
>>> This is something that should be adoptable as part of the linux filesystem<br>
>>> hierarchy.<br>
>>> I don't think it should be .nepomuk as that might alienate gnomes.<br>
>>> If all metadata is rdf .rdf might be a good choice.<br>
>><br>
>> I would personally go for .nepomuk for now since there will be no<br>
>> collaboration with Gnome anyway (well, at least I do not believe in it<br>
>> after trying for several years. But maybe you would have more luck ;)<br>
>><br>
>> Cheers,<br>
>> Sebastian<br>
>><br>
> That is one reason why I would rather keep things simple and stand-alone.<br>
> Rather than starting from the nepomuk or xesam ontologies and trying to force<br>
> one on the other.<br>
<br>
</div></div>A certain degree of commitment to the ontologies is required. Otherwise<br>
we loose too much information and the result will not be useful to<br>
Nepomuk. That said, what I mean is the meta-meta-data we use, ie. named<br>
graphs and stuff like modification dates and creators and so on.<br>
<div><br>
> I would rather stay out of that fight for now and offer an additional means of<br>
> interchanging data. :)<br>
<br>
</div>There is no fight really, especially since Tracker (Gnome) does use the<br>
Nepomuk ontologies, too. :)<br>
<br>
Cheers,<br>
<font color="#888888">Sebastian<br>
</font><div><div></div><div><br>
><br>
> Regards,<br>
><br>
> Bruce.<br>
><br>
><br>
_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<div>Ignacio</div><div><br></div><br>
</div>