Hi Danny,
You wrote:
> I've recently been doing a little electric guitar modding, and I'm
> wondering how best to describe the (material) results in RDF.
Well, first of all you should clarify why you want a description in RDF
for which kind of application. There is no conceptualization without
context of application.
> A fairly generic application of what I'm after would be to describe a
> (composite) product in a company catalogue, while also allowing their
> repair department to talk about a particular customer's broken product
> and its parts.
[...]
> Here's an example of the kind of information I want to represent:
>
> This particular guitar is a one-off custom build, I call it the
> Tinocaster. It's generic type would be Stratocaster (which is a Fender
> trademark, usually applied to products made by them, but is in common
> usage for the style). The pickup in the bridge position is a TV Jones
> Magna'Tron, a humbucker. It's in their TV'Tron mount, the traditional
> Gibson humbucker form factor.
To specify that a resource is part of another resource you should think
about using one of these properties:
http://swoogle.umbc.edu/2005/modules.php?name=Ontology_Dictionary&file=lookup_term&query=partOf&searchOption=4&start=1&total=-1
So how about http://purl.org/dc/elements/1.1/isPartOf ? It's definition
is "The described resource is a physical or logical part of the
referenced resource"
> It's quite rich information conceptually, you need to talk about
> relationships involving instruments and their parts in general as well
> as individual instruments and their individual parts.
Do you have a use case for the relationships involving instruments and
their parts in general? Maybe part-whole for the individual instruments
and instance- or subject-relations between general classes and
individuals is all that you need. What is the meaning of an individual
instrument beeing an instance of of a general type of instrument?
> Because of these different facets, I believe rather more than direct
> use of RDFS's class hierarchies is needed, SKOS maybe augmented with a
> bit of OWL seems a likely candidate.
What's wrong with OWL and RDFS? I better think SKOS may be a choice
because you don't want strict semantics on "Stratocaster" (where does
"Stratocaster" begin and where does it end?) but use it as a general
Concept without formal definition. If you want restrictions and
inference that you probably (also) need OWL, for instance for the
transitivity. Maybe this helps:
http://esw.w3.org/topic/PartWhole
> The only vocabulary shaped like this of which I'm aware is that of
> FRBR (Functional Requirements for Bibliographic Records) [1], which
> makes distinctions between Works, Manifestations, Items and
> Expressions. But I'm really not sure how reusable this is in the
> domain I have in mind as the target objects in FRBR are a little more
> abstract (artistic works rather than engineered planks).
This would be a very uncommon application of FRBR? Anyway it depends on
you application. What information exactely do you want to express?
> I did find a draft note from SWBPD [2] on Part-Whole relationships,
> but this focusses on OWL DL. While I would prefer to stay
> DL-consistent, my primary aim is to have data to work with simple
> SPARQL queries.
An old fashioned relational database design is not a bad way to start
from. Once you know your basic concepts and relations you can try to
find and/or define appropiate RDF vocabularies.
Greetings,
Jakob
--
Jakob Voß <jakob.voss@gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de