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

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

Received on Wednesday, 7 July 2010 14:45:45 UTC