- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Mon, 01 Nov 2010 17:03:07 +0100
- To: Ross Singer <ross.singer@talis.com>
- CC: Karen Coyle <kcoyle@kcoyle.net>, public-lld <public-lld@w3.org>
On 11/1/10 3:43 PM, Ross Singer wrote: > On Mon, Nov 1, 2010 at 10:11 AM, Karen Coyle<kcoyle@kcoyle.net> wrote: >> Quoting Ross Singer<ross.singer@talis.com>: >> >>> On Mon, Nov 1, 2010 at 6:31 AM, Haffner, Alexander<A.Haffner@d-nb.de> >>> wrote: >>> >>>> However, back to the formats I don’t want to discuss J foaf doesn’t have >>>> the >>>> power to reflect our comprehensive data – I thought we want to make this >>>> high quality data available for the public –if so we should have a closer >>>> look modeling the data in FRBRer, FRAD and/or RDA in parallel to the SKOS >>>> representation. >>>> >>> I keep seeing this statement getting made: "FOAF/SKOS are not >>> expressive enough for our data" and I'm simply not buying it. >>> >>> Can somebody please back up this claim? FOAF defines personal and >>> organizational entities. SKOS defines concepts. >>> >>> Those are exactly the things we're describing. >> >> Ross, at a class level you are right. But if you look at the properties >> defined by foaf and the properties used in FRAD, there is virtually no >> overlap. So I think when people make that claim, they are talking about >> available properties, not classes. >> > Right, and I have no issue with coining new properties where there are none. > > My point is simply that RDA, FRBRer and their ilk should avoid > defining classes wherever possible, since "type", I think, is the > easiest starting point for somebody (or something) to figure out what > exactly it's looking at. > > I would avoid subclassing where possible, as well, since I think ratio > of agents with reasoning is likely to go down as linked data becomes > more mainstream. Simple agents won't understand that rda:Person is a > kind of foaf:Person and unless there is some huge payoff I'm just not > seeing, it seems like would just further alienate us. > Well, I was in fact going to advice subclassing to Jeff. With the combination of his "contributor" and "aggregator" perspective in one dataset, the VIAF story becomes much more difficult to grasp if you don't make the distinction between "central" concepts and "local" ones. Having all of them represented as concepts without further refinement would probably make it more difficult to grasp the "business" logic behind VIAF's aggregation process and the very specific status of the hub concepts VIAF create (which might be ore:Aggregations at the same time). I see the point in relying on inferencers to get truly interoperable data. But this issue may often be tackled by having the data publisher materialize the result of the most crucial axioms and use multiple type statements, e.g.: x rdf:type viaf:VIAFAggregationConcept , skos:Concept . That's not utterly elegant, but it does allow to capture everyone's perspective on the data, at its very source. Cheers, Antoine
Received on Monday, 1 November 2010 16:03:22 UTC