[Nepomuk] Fwd: sequences

[Bèrto ëd Sèra]

>
> Hi all again,
>

So, let's make a further step, by including all the suggestions I got from
Sebastian

@PREFIX foo: <http://foo.bar/types#>

/* "Profile" is our DSL lingo for "meaning",
    see
http://en.wikipedia.org/wiki/Cognitive_semantics#Langacker:_profile_and_base
 */
foo:Profile rdf:type rdfs:Class .

/* A "Region" has a textual  description, along with other minor properties,
so we
   want it to inherit all translation capabilities from Profile */
foo:Region rdf:type rdfs: Class.
foo:Region rdfs:subClassOf foo:Profile .

/* A "TaxonomyEntry" is actually a user Class, we simply choose a name that
would
not mess up with programming languages */
foo:TaxonomyEntry rdf:type rdfs: Class.
foo:TaxonomyEntry rdfs:subClassOf foo:Profile .

/* A "CommunicativeSystem" is usually a human language, but we don't call it
language as it can be a protocol for software.
   For example, I can store as a synonym of part_445D (say it's a mechanical
component) its CAD/CAM representation. We will
   consider it a "translation for non-humans", i.e. for a software. This is
why I'm avoiding xd:language, because that implies a
   language being "valid", but I cannot seem to find out what makes a
language valid for it... */
foo:CommunicativeSystem rdf:type rdfs: Class.
foo:CommunicativeSystem rdfs:subClassOf foo:TaxonomyEntry .

/* A "Medium" is usually a human script, but it could be a protocol version
or
   "analogic" (audio, that is). Here there added properties
   like text rendering direction, accessibility data (a script
   needs eyesight, audio needs hearing, etc) */
foo:Medium rdf:type rdfs: Class.
foo:Medium rdfs:subClassOf foo:TaxonomyEntry .

/* A "MediumRelease" is used to track orthographic reforms, such as those in
German or Dutch */
foo:MediumRelease rdf:type rdfs: Class.
foo:MediumRelease rdfs:subClassOf foo:MediumRelease .

/* This is where actual content is, at metalevel */
foo:Content rdf:type rdfs:Class .

/* This is how we group a generic content into a given meaning */
foo:means rdf:type rdf:Property .
foo:means rdfs:domain foo:Content .
foo:means rdfs:range foo:Profile .

/* This is how we assign a language. */
foo:inCommunicativeSystem rdf:type rdf:Property .
foo:inCommunicativeSystem rdfs:domain foo:Content .
foo:inCommunicativeSystem rdfs:range foo:CommunicativeSystem .

/* This is how we assign a script. */
foo:inMedium rdf:type rdf:Property .
foo:inMedium rdfs:domain foo:Content .
foo:inMedium rdfs:range foo:Medium .

However, I'm unclear if such a declaration would allow the engine to accept
a MediumRelease in instead, for those languages that need it.

/* This is how we track translations. Client code must avoid infinite
recursions here */
foo:isTranslationOf rdf:type rdf:Property .
foo:isTranslationOf rdfs:domain foo:Content .
foo:isTranslationOf rdfs:range foo:Content .

/* If an instance of content gets modified, all of its translations are
marked "fuzzy" by this flag */
foo:isVerified rdf:type rdf:Property .
foo:isVerified rdfs:domain foo:Content .
foo:isVerified rdfs:range xsd:boolean .

/* This is how we add actual text content.
   The semantics for hasText is that the actual textual content doesn't
exist anywhere in the external filesystem
   it comes here as a property. It is different with files, that ARE stored
in the filesystem, so it takes a lot of
   polymorphism here. I hope the xs:string type is unicode. */
foo:hasText rdf:type rdf:Property .
foo:hasText rdfs:domain foo:Content .
foo:hasText rdfs:range xsd:string .

/* and this is definitely a relation, as it only points to an external file.
Probably nao:isRelated
   would fit in perfectly, as long as I can enforce that an instance of
Content gets related to one
   and only one file. */
foo:hasFile rdf:type rdf:Property .
foo:hasFile rdfs:domain foo:Content .
foo:hasFile rdfs:range File .

/* Let's subclass Content into expressions and definitions so we know on
which
   side of the equation expr = def we need to place the content. For all
basic functionality
   they simply inherit Content */
foo:Expression rdf:type rdfs: Class.
foo:Expression rdfs:subClassOf foo:Content .
foo:Definition rdf:type rdfs: Class.
foo:Definition rdfs:subClassOf foo:Content .

/* This assigns content to a Region and it could definitely be nie:isPartOf,
as long as we don't get into confusion in queries */
foo:belongsTo rdf:type rdf:Property .
foo:belongsTo rdfs:domain foo:Content .
foo:belongsTo rdfs:range foo:Region .

>
> Are my comments helpful or are you looking for something else?
>
They are really helpful, as I start to have a first idea of the way nepomuk
works.

Bèrto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100921/f391a6d1/attachment.htm