Re: How to describe composite products..?

On 03/04/07, Jakob Voss <jakob.voss@gbv.de> wrote:
> Hi Danny,

Thanks Jakob,

> 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.

The application is the Semantic Web. The only concrete context is the
information with which I'm surrounded while playing with guitar bits.
I can't guess the target applications of anyone for whom the data may
potentially be useful, even my own future application contexts are as
yet undefined.

But there are immediate aspects I can be more sure of. Initially I'd
like to use simple queries against the data to present different
facets. I would also like to use browser/viewers such as Longwell and
Tabulator to present and navigate the data describing the guitar(s)
alongside to-be-discovered related data on the web. Ultimately I'd
like to be able to ask the web things like "what inexpensive pickup
goes well with a chestnut body and maple neck for producing the kind
of sounds associated with psychobilly music". Right now that takes a
lot of research, money, splinters & aspirin to answer.

> > 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"

I'm not sure that alone adequately describes the (at least) two
different ways part-of is needed here - in particular separating
classes (guitars and pickups) and instances (the one & only Tinocaster
and its Magna'Tron).

> > 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?

There will be characteristics shared across all individuals of the
type - with the Stratocaster it's probably the shape, with humbucker
pickups it's the coil configuration.

> > 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

Thanks, I'd momentarily forgotten the Wiki ;-)

> > 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?

For starters, the paragraph above.

> > 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.

Hmm, the problem looks the same in RDB terms, I still have to figure
out the basic concepts and relations...

Cheers,
Danny.

-- 

http://dannyayers.com

Received on Tuesday, 3 April 2007 13:36:14 UTC