Re: [open-bibliography] MARC Codes for Forms of Musical Composition

Well, ok, there are two problems with your example.

1) your foaf:Person and bio:Birth aren't related in any way.  You need a
bio:event predicate on your foaf:Person or a bio:principal predicate on your
bio:Birth (or both).  This would clearly and unambiguously clear up any
confusion.
2) The person is not the "group".  He or she can be a mo:SoloMusicalArtist
or a member of mo:MusicGroup with his or her name (although I don't know of
any examples of this).  But a person can't be a group.

I'm not saying because it's the way things have been done that it's the way
things must be done.  The discussion on the SKOS list have pretty clearly
been limited to whether or not skos:Concepts can also be the thing they're
the concept of.  KOSs are, I think, somewhat unique in this regard (that is,
is the subject of something a superset, subset or equal to the thing it's
describing?).

That being said, if the more common practice in the linked data cloud is to
allow for multiple types to exist on a single resource and you, for whatever
reason, think this is wrong, I think you at least need to wonder why you are
standing in the minority.  You may very well be right that it's not the
right thing to do, but I think this is going to be a tough hill to climb
(and you're going to have to make the argument more convincingly).

-Ross.

On Wed, Jul 7, 2010 at 4:30 PM, Houghton,Andrew <houghtoa@oclc.org> wrote:

> > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Ross Singer
> > Sent: Wednesday, July 07, 2010 02:55 PM
> > To: Young,Jeff (OR)
> > Cc: Erik Hetzner; public-lld
> > Subject: Re: [open-bibliography] MARC Codes for Forms of Musical
> Composition
>
> >I guess what I'm saying is that this viewpoint has no basis in the common
> practice of how linked data is being created currently.
>
> With respect, that is not an argument...
>
> Just because it has been done forever, since the dawn of time,
> doesn't mean that it is correct:
>
>  Witness Apple's iPhone signal strength bars... works great on
>  iPhone, iPhone 3G, iPhone 3Gs, oops... iPhone 4G its been wrong
>  since the dawn of time...
>
> DBPedia is a poor example to use for common practice. It certainly
> is a large dataset, but only one dataset. Also, there has been
> numerous discussions on the SKOS list over the past year about
> DBPedia's describing resources with multiple rdf:type is not
> considered "good" practice.
>
> Jeff Young and I were just talking a bit about issues around
> conflation of individuals. What if you had a person and music
> band by the same name because the person is a solo singer. So
> you describe the person as foaf:Person and the band as
> foaf:Group or foaf:Organization. Since foaf: does not include
> a property to specify birth date you decide to use the bio
> ontology to supplement the foaf: ontology:
>
> <foaf:Person rdf:about="#Me">
>  <bio:Birth rdf:parseType="Resource">
>    <dct:date>2000-01-01</dct:date>
>  </bio:Birth>
> </foaf:Person>
>
> <foaf:Group rdf:about="#Me" />
>
> Because the triples have the same subject: is bio:Birth
> associated with the foaf:Group or the foaf:Person? Doesn't
> make any sense that a band has a birth date does it? Maybe
> a startup/disband date. This is the sort of nonsense you
> wind up with when you conflate individuals and you use
> properties declared outside the ontology described by
> rdf:type.
>
> Things can even get complex for properties in the ontology
> specified by rdf:type. An OWL reasoner could deduce that a
> property with a domain foaf:Person can only be associated
> with the foaf:Person description, but what about a property
> that has multiple domains? Which class in the conflation
> does it belong to? When you conflate individuals, you start
> having problems making sense of what is being said about
> what.
>
> BTW, sure I can intuit that bio:Birth should go with the
> foaf:Person, but can a machine do that for any unknown
> ontology... most likely not.
>
>
> Andy.
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those
> of Talis Information Ltd or its employees. The content of this email message
> and any files that may be attached are confidential, and for the usage of
> the intended recipient only. If you are not the intended recipient, then
> please return this message to the sender and delete it. Any use of this
> e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is
> registered in England No 3638278 with its registered office at Knights
> Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>