W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2005

skos documentation properties, alternatives

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Sun, 27 Feb 2005 23:14:27 +0100
To: public-esw-thes@w3.org
Message-ID: <PM-EH.20050227231427.D53C5.2.1D@192.168.27.2>


ok, this is an attempt to summarize some alternatives
for modeling SKOS' documentation properties.

use cases/patterns:
- maintain/store plain note content
- maintain/store structured note content
- maintain/link to remote note document

####### current approach: ########
- n terms
   - 0 classes
   - n general rdf:Properties
- each property can be used to link a concept
  to either a literal value, a (blank) untyped
  note node, or a document.
- use case examples:
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:example>bar</skos:example>
      </skos:Concept>
   ]]]
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:example rdf:parseType="Resource">
            <rdf:value>bar</rdf:value>
         </skos:example>
      </skos:Concept>
   ]]]
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:example rdf:resource="bar.html" />
      </skos:Concept>
   ]]]
- advantages:
   - only n terms need to be invented
- (potential) disadvantages:
   - interpretation of instance data and auto-
     generating forms can't be unambiguously done
     by looking at the model only
   - instance data may need to be pre-processed
     to be usable with OWL DL systems

####### alternative approach 1: ########
- n*2 terms
   - 0 classes
   - n owl:DatatypeProperties
   - n owl:ObjectProperties
- separate properties are used
- use case examples:
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:example>bar</skos:example>
      </skos:Concept>
   ]]]
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:exampleNote rdf:parseType="Resource">
            <rdf:value>bar</rdf:value>
         </skos:exampleNote>
      </skos:Concept>
   ]]]
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:exampleNote rdf:resource="bar.html" />
      </skos:Concept>
   ]]]
- advantages
   - unambiguous use of documentation properties
   - OWL DL-happy (?)
- disadvantages
   - doubled number of documentation properties
   
####### alternative approach 2: ########
- n+2 terms
   - n classes
   - 1 owl:DatatypeProperty
   - 1 owl:ObjectProperty
- a single object property is used to link a concept
  to a note, notes can be typed.
- use case examples:
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:note>
            <skos:Example>
               <skos:noteValue>bar</skos:noteValue>
            </skos:Example>
         </skos:note>
      </skos:Concept>
   ]]]
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:note>
            <skos:Example>
               <skos:noteValue>bar</skos:noteValue>
            </skos:Example>
         </skos:note>
      </skos:Concept>
   ]]]
   [[[
      <skos:Concept rdf:about="#foo">
         <skos:note>
            <skos:Example rdf:about="bar.html" />
         </skos:note>
      </skos:Concept>
   ]]]
- advantages
   - unambiguous use of documentation properties
   - more or less the same serialization for any
     use case
   - OWL DL-happy (?)
   - untyped notes are possible
   - notes can get multiple types (e.g. a public
     editorialNote, types from other vocabs)
   - facilitated querying (?)
- disadvantages
   - serializations are a little bit more complex
   - no plain literal notes (which doesn't really
     facilitate the generation of simple editing
     forms)

hope this is helpful at all, still looks like a job
for the vocab management task force..


regards,
benjamin

--
Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany
http://www.bnode.org/
Received on Sunday, 27 February 2005 22:14:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:53 GMT