- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Tue, 3 Apr 2007 15:36:07 +0200
- To: "Jakob Voss" <jakob.voss@gbv.de>
- Cc: public-esw-thes@w3.org
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