RE: MARC Codes for Forms of Musical Composition

> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On Behalf Of Bernard Vatant
> Sent: Thursday, July 08, 2010 05:34 AM
> To: public-lld
> Subject: Re: MARC Codes for Forms of Musical Composition

> 2. I'm amazed that one would debate about unicity of rdf:type at all. It's certainly a good practice for the URI publisher to declare a single rdf:type. But based on OWL or RDFS semantics, other types will be entailed even if they are not declared.

I wasn't arguing or debating the unicity of rdf:type, but instead as your next sentence states: "It's certainly a good practice for the URI publisher to declare a single rdf:type." My intent was to have this *considered* as a best practice and *wasn't* saying multiple rdf:type's should never be used, but stating there are some use cases where its difficult to reconstruct the publishers intent after RDF merges the triples when the publisher uses multiple rdf:type's. Even if this view doesn't become a best practice, it would be useful to document the tradeoffs between using multiple vs. single rdf:type's for publishers, which might also include William Waits suggestion, see below.

> That said, in an open world, an application will be able to pick in the descriptions the elements it can consume. If something (someone) is declared with rdf:type foaf:Person and entailed some way to be also skos:Concept, if my application is interested in the social aspects of the description for a social web applications, I will consider only the triples with predicates in the FOAF namespace, and if your application is interested only by this resource as an entry in a resource index, using e.g. dcterms:subject or dcterms:creator, you will pick only the predicates in the SKOS namespace (prefLabel, altLabel ...)

I think I said this earlier. An application can easily pick out properties in the namespace associated with rdf:type. That's not a concern. The concern is when publishers use properties from other namespaces, such as DC, then applications cannot determine which of those rdf:type's it belongs to. In some use cases it just doesn't matter in other use cases it does. A publisher could sidestep this issue by declaring their own namespace and using rdfs:subPropertyOf as William Waits suggested in another message [is there a best practice here?]. But there are still subtle issues when the publisher declares a new property in their namespace that has multiple rdfs:domain's and the individual uses both those rdf:type's, then an application still might not be able to tell.

> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Ed Summers
> Sent: Wednesday, July 07, 2010 11:36 PM
> To: public-lld
> Subject: Re: [open-bibliography] MARC Codes for Forms of Musical
> Composition
> 
> In principle I kinda agree with Andy that keeping it simple is often a
> good place to start out -- and to only start making things complicated
> with multiple types when you feel like you have to. I think it's
> important to be clear about the resources you are identifying and
> describing. But that doesn't preclude assigning multiple types to a
> resource, if you think the resource can be seen in different
> lights/contexts, and you want to help people do that.

Ed does a good job here of summarizing my viewpoint!

> From: William Waites [mailto:william.waites@okfn.org] 
> Sent: Wednesday, July 07, 2010 10:54 PM
> To: Houghton,Andrew
> Cc: Ross Singer; public-lld; Young,Jeff (OR)
> Subject: Re: [open-bibliography] MARC Codes for Forms of Musical Composition

> Somewhat tangentially, I don't understand how using rdfs:seeAlso *implies* that the target resources are variant representations, it only says that there might be some related information over there, the question of "related how?" is left open. Continuing, I assume there is some predicate, xyz:variantRepresentation that has the meaning that you want.

I wasn't suggesting rdfs:seeAlso *implies* a variant representation, only that it was one of many linking properties that could be used to describe a relationship between the two URI's. There are linking properties in DC, UMBEL, etc. that could also be used or as you suggest create your own. Also, the idea of *variant representation* was pulled from the analogy with the TAG GenericResource-53 finding in the Web Architecture space. I was mearly suggesting that those things, e.g., foaf:Person or skos:Concept act in a similar fashion to *variant representation* and *if* you subscribe to the TAG GenericResource-53 finding analogy, each would have been given a separate URI.

BTW, List Admin, I only seem to be getting half this conversation. Especially, no messages from anyone in my own organization... but others have made quotes to messages that I have not received!?


Andy.

Received on Thursday, 8 July 2010 15:18:22 UTC