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

Ross,

 

I'm not familiar with Ruby, so that particular analogy doesn't help me.
I will try to make my point without resorting to analogy.

 

I agree my foaf:Person and foaf:Organization example isn't good because
they are disjoint. Let me see if I can make my point using your
foaf:Person/mo:MusicArtist/sioc:User counterexample.

 

Note that sioc:User has been deprecated in favor of sioc:UserAccount.
Given this subtle change, are you still comfortable saying only one URI
is needed to cover these three types?

 

Jeff

 

From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On Behalf Of
Ross Singer
Sent: Wednesday, July 07, 2010 11:29 AM
To: Young,Jeff (OR)
Cc: Erik Hetzner; public-lld
Subject: Re: [open-bibliography] MARC Codes for Forms of Musical
Composition

 

Jeff, I don't think it's helpful to think about this in the context of
Java's object inheritence.  I think a better analogy would be Ruby's
notion of mixins (although it's still not the same, it's just *more*
similar to the RDF model than Java's).  In this analogy, rdfs:Resource
would be like Object and rdfs:Class would be like Module.  It helps when
you think of it in some serialization other than rdf/xml, too.

 

<http://example.org/foo> 

      a foaf:Person;

      foaf:name "John Doe".

 

It's not a tremendous stretch to think of this like:

 

module FOAF < RDFSClass

  attr_accessor :name, :nick, depiction

end

 

module FOAF::Person  

  attr_accessor :surname, :firstName, :knows

end

 

class Resource < RDFSResource

end

 

me = Resource.new

me.extend(FOAF::Person)

me.name = "John Doe"

 

 

You can't have a foaf:Person that's also a foaf:Organization, anyway
(they are disjoint with each other).

 

A better example is that you have a foaf:Person who is also
mo:MusicArtist and a sioc:User.  We shouldn't need three URIs to define
this person, but attributes of all three classes are necessary (or
useful) to accurately describe him/her.

 

-Ross.

On Wed, Jul 7, 2010 at 10:45 AM, Young,Jeff (OR) <jyoung@oclc.org>
wrote:

Erik,

I agree and admit that I wasn't thinking clearly when I first brought it
up. Let me see if I can salvage my thought.

I'm looking at Linked Data from an object-oriented perspective. For
example, Java has a class extension mechanism that is roughly analogous
to rdfs:subClassOf. When I use "new" to create a Java object, I can only
apply it to one and only one Java class. As with RDF, I agree that this
one new individual is automatically an instance of all the other classes
in the hierarchy.

What I can't do in Java, though, is instantiate an ad hoc combination of
Java classes like org.example.Corporation and org.example.Person. If
this feature existed in Java, it would (arguably?) add complexity and
obscurity. In OWL/RDF, this kind of restraint must be self-imposed.

If this same kind of self-restraint was adopted for RDF, URI patterns
could be more transparent without compromising the reasons for opacity.
For example:

http://example.org/foaf:Person/12345

<rdf:RDF ...>
<foaf:Person rdf:about="http://example.org/foaf:Person/12345" />
</rdf:RDF>

http://example.org/foaf:Organization/67890

<rdf:RDF ...>
<foaf:Organization
rdf:about="http://example.org/foaf:Organization/67890" />
</rdf:RDF>

(Note that the particular URI pattern I'm showing is illustrative and
not required for my argument.)

Since foaf:Person and foaf:Organization are both subclasses of
foaf:Agent, I could imagine these (optional) URIs facilitating
discoverability at the protocol level as well:

http://example.org/foaf:Agent/12345 (302 redirect to
http://example.org/foaf:Person/12345)
http://example.org/foaf:Agent/67890 (302 redirect to
http://example.org/foaf:Organization/12345)

Since everything is ultimately an owl:Thing, this principle could be
taken to its logical conclusion:

http://example.org/owl:Thing/12345  (302 redirect to
http://example.org/foaf:Person/12345)
http://example.org/owl:Thing/67890  (302 redirect to
http://example.org/foaf:Organization/12345)

This brings up use cases where an individual is arguably both
foaf:Person and foaf:Organization (e.g. royalty?). This situation can be
resolved in Java, though, without a new operation involving multiple
classes at once. Analogous solutions could be systematically applied to
the production of RDF.

Jeff


-----Original Message-----
From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
Behalf Of Erik Hetzner
Sent: Tuesday, July 06, 2010 3:58 PM
To: public-lld
Subject: Re: [open-bibliography] MARC Codes for Forms of Musical
Composition

(Sorry for the spam; this was sent from the wrong email address, so I
am re-sending.)

At Tue, 06 Jul 2010 10:07:56 -0700,
Erik Hetzner wrote:
>
> At Tue, 6 Jul 2010 12:27:17 -0400,
> Young,Jeff (OR) wrote:
> > Let me address Ross' question before attempting to argue that
restraint
> > to a single rdf:type is good practice.
> >
> > Here is the example in question:
> >
> > http://purl.org/NET/marccodes/muscomp/sy.rdf
>
> Hi,
>
> Once you bring OWL into the picture, every resource has rdf:type
> owl:Thing in addition to any defined rdf:type. Any rdfs:Class (C) that
> is rdfs:subClassOf another class (C') implies that every instance of
> type C is also of type C'. I would argue that a resource with multiple
> (implied) rdf:type(s) is the rule, not the exception.
>
> best, Erik Hetzner




Please consider the environment before printing this email.

Find out more about Talis at http://www.talis.com/
shared innovation(tm)

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.