DC with RDF Modeling Questions

I'm developing an RDF application, but I have some questions that I have
not found in the W3C documentation, in case any kind soul feels like
helping me.

It is clear that I should re-use existing ontologies whenever possible.
Thus, I am using some of the Dublin Core elements/refinements, e.g. I'm
using dc:title to hold the primary info of a class called "EngineeringName"
that I'm using to encode a list of existing corporate terms.

Q1:  Should I still define any dc concepts in RDFS?  (I'm guessing 'yes',
but it's not clear to me.)

Q2:  Is the use of QNames ok in the value of an rdf:ID attribute, as with
the following 'dc:title', where I also have the appropriate namespace
assignment to the prefix?

<rdf:Property rdf:ID="dc:title"/>          <--- Is 'dc:title' OK to use
this way????  Should I use an entity instead of the prefix????
     <rdfs:domain rdf:resource="#EngineeringName"/>
</rdf:Property>

Separate topic:

Each engineering object, e.g. a body control module, gets realized in
physical form as parts shipped from suppliers.  For a given engineering
object, there may be more than one corresponding part number (e.g. PN 1234
from supplier A and PN5678 from supplier B may both be functionally
equivalent body control modules).  I want to have a pointer from the
resource representing the engineering object to a bag of such part numbers
that represent the physical realizations of that object.

Q3:  It seems to me that a part number is a version/edition/adaptation of
an engineering name, and thus it is reasonable to model the relationship
with dc:hasVersion, as in the following instance:

<EngineeringName rdf:about="12F/0100A">
       <dc:title> Body Control Module</dc:title>
      <dc:hasVersion> <rdf:Bag>  <rdf:li  PN1234 />  <rdf:li PN5678/>
</rdf:Bag></dc:hasVersion>
</EngineeringName>

Does this appear reasonable/correct to you?

Thanks, in advance.


Kurt Godden
GM Technical Fellow
GM R&D, Warren, MI
ph: 586-986-0445; em: kurt.godden@gm.com

"I distrust a research person who is always obviously busy on a task."
   ---Robert A. Frosch, VP (retired), GM Research

Received on Tuesday, 20 July 2004 12:49:31 UTC