Sorry, I had mistakenly sent this email to Sebastian only...<br><br><div class="gmail_quote">Hi!<br><br><div class="gmail_quote"><div class="im">On 16 September 2010 19:46, Sebastian Trueg <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">
It is not recommended to use RDF containers. They cannot properly<br>
queries via SPARQL, support is not guranteed, and their semantics are<br>
very unclear anyway.<br>
Thus, I follow popular opinion in the semantic world and recommend not<br>
to use them.</blockquote></div><div> Duly noted. We have an already high risk factor "as is", we won't be looking for additional trouble.</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
</div>If you need to store more information then you need to go the normal RDF<br>
way: define the ontology constructs you need. We will be happy to help<br>
you with that.<br></blockquote></div><div>Okay, I'll try to use the example I found on the ontologies, so you can correct my misunderstandings as I go on. I put in the end, as some explanations may be of help before that.</div>
<div class="im">
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Thus, please think twice before trying to store anything in the</div>
graph/context metadata. In most cases a specific class or property might<br>
make more sense.<br></blockquote><div> </div></div><div>Again, whatever does the job better and with less trouble is welcome. </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br>
</div>Could you maybe elaborate a bit on your project?<br></blockquote></div><div>It's a simple idea: we collect external data sources, like wiktionary, AGROVOC, geographic names, public open source DBs etc and put them into a common format that allows a single interface for them all. In our DSL the prepared data from a single source is called a "region". We have bots doing the collect/update job for a region, and since data is semantically tagged, a user may say "I want everything about Tai-chi, vegan food and astronomy from the following regions in English and Japanese". His machine downloads the prepared normalized data from a list of network-sources to keep up-to-date. While these bot driven regions are read-only the user can also upload back stuff to the same network-sources using a "community region", in order to share it. There may be any number of communities, as we expect people to develop thematic communities or simply to dislike each other POVs, sooner or later, and communities are self managed. If I don't like a community I don't link their stuff, and that's it. Anyway, this is a further development, we will have just one community, to begin with.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Could you also elaborate on the distributed rep, please. Be aware that</div>
Nepomuk does not provide a distributed store and it is very unlikely<br>
that it will in the near future - simply because creating a distributed<br>
store is very very hard, a lot of work, and requires expertise that we<br>
do not have...<br></blockquote><div> </div></div><div>We have no idea about how to make a "real" distributed store, either. The doable thing I can think of is, as I said, a list of network-sources that can import and distribute a number of "regions" to end users. But I tend to think that since we have to upload stuff back to a "community region" two laptops could sync each other using any network connection in place. So, for example, if I live in an insulated village in the middle of nothing (a common situation in the third world) and I have but one box in a school, anyone coming to visit with a laptop can update me, provided that I told him what to download when he could get a normal connection and he has storage space enough for it. Or I could remain in the village and be sent a RAM key or a DVD with updates on it. This would already be a lot, for most "randomly connected" situations. Most of Africa and a lot of Asia has little choice other than this, and it's especially for them that accessing "thematic knowledge" locally is a high value.</div>
<div><br></div><div>I suppose that since dbpedia has RDF exports there should be RDF imports, and we could just use this. Once export files are available, they could be broadcast using the p2p features (which I know nothing of, I just know they should be there, sooner or later). Since we do multimedia content, this is especially important to limit the amount of content one wants to store. To remain with our previous example, my subscription could be: "I want everything about Tai-chi, vegan food and astronomy from the following regions in English and Japanese, excluding video and audio files, pictures included". In any case I would get pointers to remote resorce uuids, telling me there's a video/audio file (and its tags), so that I can know it's there and I can order single downloads if I decide some particular material is of interest. </div>
<div><br></div><div>Now let's get to the model. "Profile" is our DSL lingo for "meaning", see <a href="http://en.wikipedia.org/wiki/Cognitive_semantics#Langacker:_profile_and_base" target="_blank">http://en.wikipedia.org/wiki/Cognitive_semantics#Langacker:_profile_and_base</a> :</div>
<div><br></div>@PREFIX foo: <<a href="http://foo.bar/types#" target="_blank">http://foo.bar/types#</a>> </div><div class="gmail_quote">foo:Profile rdf:type rdfs:Class .</div><div class="gmail_quote"><br></div><div class="gmail_quote">
/* A "Region" has a textual description, along with other minor properties, so we want it to inherit all translation capabilities from Profile */</div><div class="gmail_quote">foo:Region rdf:type rdfs: Class.</div>
<div class="gmail_quote">foo:Region rdfs:subClassOf foo:Profile .</div><div class="gmail_quote"><br></div><div class="gmail_quote">/* This is where actual content is */</div><div class="gmail_quote">foo:Content rdf:type rdfs:Class . </div>
<div class="gmail_quote">foo:Text rdf:type rdfs:Class .</div><div class="gmail_quote">foo:File rdf:type rdfs:Class . </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">foo:means rdf:type rdf:Property . </div><div class="gmail_quote">foo:means rdfs:domain foo:Content . </div><div class="gmail_quote">foo:means rdfs:range foo:Profile . </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">/* Here I'm in trouble, as I need what DBs call an ENUM(expression, definition) that defines the role a Content instance in a dictionary expr=def equation. You will excuse my "creative syntax", probably I should have created a "Role" class with two instances, right? */</div>
<div class="gmail_quote"><div class="gmail_quote">foo:hasRole rdf:type rdf:Property . </div><div class="gmail_quote">foo:hasRole rdfs:domain foo:Content . </div><div class="gmail_quote">foo:hasRole rdfs:range foo:(expression,definition) . </div>
</div><div class="gmail_quote"><br></div><div class="gmail_quote">/* How do we avoid infinite recursions here? */</div><div class="gmail_quote"><div class="gmail_quote">foo:isTranslationOf rdf:type rdf:Property . </div><div class="gmail_quote">
foo:isTranslationOf rdfs:domain foo:Content . </div><div class="gmail_quote">foo:isTranslationOf rdfs:range foo:Content . </div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">/* Do we have Booleans? Anyway, if an instance of content gets modified, all of its translations are marked "fuzzy" by this flag */</div>
<div class="gmail_quote"><div class="gmail_quote">foo:isVerified rdf:type rdf:Property . </div><div class="gmail_quote">foo:isVerified rdfs:domain foo:Content . </div><div class="gmail_quote">foo:isVerified rdfs:range foo:Boolean . </div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">/* Now these two properties are on a mutex constraint, something is either a text of a file. Not sure whether this distinction is important for nepomuk, in PostgreSQL we use it to separate things we can set a full-text search on from things that must be searched otherwise. Content is also used as a meta-level, to send out minimal information about remote files that aren't actually present on the system */</div>
<div class="gmail_quote"><div class="gmail_quote">foo:hasText rdf:type rdf:Property . </div><div class="gmail_quote">foo:hasText rdfs:domain foo:Content . </div><div class="gmail_quote">foo:hasText rdfs:range foo:Text . </div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">foo:hasFile rdf:type rdf:Property . </div><div class="gmail_quote">foo:hasFile rdfs:domain foo:Content . </div><div class="gmail_quote">
foo:hasFile rdfs:range foo:File . </div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">/* This assigns content to a Region */</div><div class="gmail_quote"><div class="gmail_quote">foo:belongsTo rdf:type rdf:Property . </div>
<div class="gmail_quote">foo:belongsTo rdfs:domain foo:Content . </div><div class="gmail_quote">foo:belongsTo rdfs:range foo:Region . </div><div class="gmail_quote"><br></div><div class="gmail_quote">Now, before I write too much garbage syntax, is this readable/usable? There is much more to come, although I expect changes to be needed, for the existing model to adapt to this new environment.</div>
</div></div></div></div></div></div></div></div><div class="gmail_quote"><div><br></div><font color="#888888"><div>Bèrto</div></font></div>
</div><br><br clear="all"><br>-- <br>==============================<br>Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacré des droits et le plus indispensable des devoirs.<br>