<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">Hi all again,</div></div></blockquote><div><br></div><div>So, let's make a further step, by including all the suggestions I got from Sebastian</div>
<div><br></div>
@PREFIX foo: <<a href="http://foo.bar/types#">http://foo.bar/types#</a>> <br><br></div><div class="gmail_quote">/* "Profile" is our DSL lingo for "meaning",<br> see <a href="http://en.wikipedia.org/wiki/Cognitive_semantics#Langacker:_profile_and_base">http://en.wikipedia.org/wiki/Cognitive_semantics#Langacker:_profile_and_base</a> */<br>
foo:Profile rdf:type rdfs:Class .<br><br>/* A "Region" has a textual description, along with other minor properties, so we </div><div class="gmail_quote"> want it to inherit all translation capabilities from Profile */<br>
foo:Region rdf:type rdfs: Class.<br>foo:Region rdfs:subClassOf foo:Profile .<br><br>/* A "TaxonomyEntry" is actually a user Class, we simply choose a name that would<br>not mess up with programming languages */<br>
foo:TaxonomyEntry rdf:type rdfs: Class.<br>foo:TaxonomyEntry rdfs:subClassOf foo:Profile .<br><br>/* A "CommunicativeSystem" is usually a human language, but we don't call it language as it can be a protocol for software.<br>
For example, I can store as a synonym of part_445D (say it's a mechanical component) its CAD/CAM representation. We will<br> consider it a "translation for non-humans", i.e. for a software. This is why I'm avoiding xd:language, because that implies a<br>
language being "valid", but I cannot seem to find out what makes a language valid for it... */<br>foo:CommunicativeSystem rdf:type rdfs: Class.<br>foo:CommunicativeSystem rdfs:subClassOf foo:TaxonomyEntry .<br>
<br>/* A "Medium" is usually a human script, but it could be a protocol version or </div><div class="gmail_quote"> "analogic" (audio, that is). Here there added properties<br> like text rendering direction, accessibility data (a script </div>
<div class="gmail_quote"> needs eyesight, audio needs hearing, etc) */<br>foo:Medium rdf:type rdfs: Class.<br>foo:Medium rdfs:subClassOf foo:TaxonomyEntry .<br><br>/* A "MediumRelease" is used to track orthographic reforms, such as those in German or Dutch */<br>
foo:MediumRelease rdf:type rdfs: Class.<br>foo:MediumRelease rdfs:subClassOf foo:MediumRelease .<br><br>/* This is where actual content is, at metalevel */<br>foo:Content rdf:type rdfs:Class . <br><br>/* This is how we group a generic content into a given meaning */<br>
foo:means rdf:type rdf:Property . <br>foo:means rdfs:domain foo:Content . <br>foo:means rdfs:range foo:Profile . <br><br>/* This is how we assign a language. */<br>foo:inCommunicativeSystem rdf:type rdf:Property . <br>foo:inCommunicativeSystem rdfs:domain foo:Content . <br>
foo:inCommunicativeSystem rdfs:range foo:CommunicativeSystem . <br><br>/* This is how we assign a script. */<br>foo:inMedium rdf:type rdf:Property . <br>foo:inMedium rdfs:domain foo:Content . <br>foo:inMedium rdfs:range foo:Medium . <br>
<br>However, I'm unclear if such a declaration would allow the engine to accept a MediumRelease in instead, for those languages that need it. <br><br>/* This is how we track translations. Client code must avoid infinite recursions here */<br>
foo:isTranslationOf rdf:type rdf:Property . <br>foo:isTranslationOf rdfs:domain foo:Content . <br>foo:isTranslationOf rdfs:range foo:Content . <br><br>/* If an instance of content gets modified, all of its translations are marked "fuzzy" by this flag */<br>
foo:isVerified rdf:type rdf:Property . <br>foo:isVerified rdfs:domain foo:Content . <br>foo:isVerified rdfs:range xsd:boolean . <br><br>/* This is how we add actual text content.<br> The semantics for hasText is that the actual textual content doesn't exist anywhere in the external filesystem<br>
it comes here as a property. It is different with files, that ARE stored in the filesystem, so it takes a lot of<br> polymorphism here. I hope the xs:string type is unicode. */<br>foo:hasText rdf:type rdf:Property . <br>
foo:hasText rdfs:domain foo:Content . <br>foo:hasText rdfs:range xsd:string . <br><br>/* and this is definitely a relation, as it only points to an external file. Probably nao:isRelated<br> would fit in perfectly, as long as I can enforce that an instance of Content gets related to one<br>
and only one file. */<br>foo:hasFile rdf:type rdf:Property . <br>foo:hasFile rdfs:domain foo:Content . <br>foo:hasFile rdfs:range File . <br><br>/* Let's subclass Content into expressions and definitions so we know on which<br>
side of the equation expr = def we need to place the content. For all basic functionality<br> they simply inherit Content */<br>foo:Expression rdf:type rdfs: Class.<br>foo:Expression rdfs:subClassOf foo:Content .<br>
foo:Definition rdf:type rdfs: Class.<br>foo:Definition rdfs:subClassOf foo:Content .<br><br>/* This assigns content to a Region and it could definitely be nie:isPartOf, as long as we don't get into confusion in queries */<br>
foo:belongsTo rdf:type rdf:Property . <br>foo:belongsTo rdfs:domain foo:Content . <br>foo:belongsTo rdfs:range foo:Region . </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
</div>Are my comments helpful or are you looking for something else?<br></blockquote><div>They are really helpful, as I start to have a first idea of the way nepomuk works.</div><div></div></div><br>
<div>Bèrto</div>