- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Wed, 15 Sep 2010 14:55:28 -0400
- To: "Ross Singer" <ross.singer@talis.com>
- Cc: "Karen Coyle" <kcoyle@kcoyle.net>, "public-lld" <public-lld@w3.org>
> You'll notice that in my example I didn't use > dcterms:hasVersion/isVersionOf, but rather rda:workManifested (which, > actually, looking more closely at it, doesn't seem right either: "A > work embodied in a manifestation." with no range -- implying a > literal?). I hope it means they haven't finished creating their OWL yet. Based strictly on intuition, the combination of rdfs:domain "Manifestation" and property name "workManifested" implies that the rdfs:range will eventually be "Work". It would be helpful if they stated this explicitly and upgraded the rdf:type from rdf:Property to owl:ObjectProperty. It would also help if they included an owl:inverseOf so we could easily discover the property name going in the other direction. Symmetry suggests it would be "manifestationWorked", but that's nonsense and suggests this property could be been named better. The better the OWL, the less guessing and digging elsewhere we will have to do. > My point actually isn't either of those, it just is making > the point that a direct relationship between M and W is useful, simple > and eliminates a lot of hand waving and teeth gnashing with no > discernible downside. Based on the above, it seems plausible to believe RDA is heading towards supporting this view using OWL. I wouldn't trust it yet, though. > And while, no, dcterms:hasVersion/isVersionOf isn't documented > anywhere, if this group saw it as useful (or any other combination of > inverse relationships, including something new) it could document, > recommend and endorse it. This sounds like a job for DC Application Profiles which I'm still skeptical/ignorant about. I have yet to see an ontology that makes me comfortable, but at least OWL lets me know how other people think. This doesn't mean I need to model my internal thoughts like theirs, but it does mean that I can and should represent my thoughts in their models if I want to them to understand me clearly and usefully. OWL makes this approach scalable. > Then your semantics are there. There is > practically zero RDF/FRBR/RDA data to draw upon presently - I don't > see the point in stubbornly sticking to the letter of a model that is > currently unproven, unused and doesn't deal well with our hundreds of > millions of legacy records. Is the FRBR model so immutable that it > cannot exist with the addition of a direct relationship between W and > M? If it eases the transition of the old into the new and reduces > costs, wouldn't that generally be considered beneficial? No doubt, something is better than nothing and improvements can be made later. I assume Karen started this thread, though, because she was looking for plausible solutions. Ignoring Expression is certainly one solution, but my argument is that support for real Expressions shouldn't be that hard: simply assume that every work implies the existence of one expression and accept the possibility this could be "wrong" in a small number of cases. > > The question is, how much grief will the RDF designer get for wanting > to > > coin a new 303 URI? If the framework is flexible, then go ahead and > have > > them coin a 303 URI for Expression: > > > > http://example.org/expression/45678 a frbr:Expression . > > > > My suggestion of using a hash assumes that Expression will always be > a > > twin to Work and is easily piggybacked on it without fighting for > > infrastructure support. If and when Expressions deserve 303 URIs, the > > old hash URIs can migrate to the 303 URI using owl:sameAs. > > > Unless assertions are applied to the Fauxpression and then you get > into reconciliation, which is expensive and most likely requires human > intervention. > If the Fauxpression is, indeed, just a placeholder that we aren't > expecting to add any assertions to -- again, I ask, what's the point? > Just to make things more complicated? I'm not suggesting the creation of fauxpressions that requires expensive human intervention later. I believe as Gordon does that "expressionless Works will be rare or short-lived". One use case he mentions is "lost" Works which by implication are unsuitable for W/M associations as well. If a Work and a Manifestation exist, then it can be unquestionably assumed that at least one Expression also exists. At the very least, we would know two (object) properties of the Expression: frbr:isARealizationOf and frbr:isEmbodiedIn. > > I guess it's just not clear to me what is lost with a three-way > relationship between W,E and M that requires this > Expression-as-sole-gatekeeper between Work and Manifestation (which, > given our historical data -- and the historical record on the > interpretation of 'what is an Expression?' -- is going to be nothing > but problematic). To recap, if a Manifestation exists, it is safe to assume that an Expression and Work also exist. At a minimum, the properties of the Expression are frbr:isARealizationOf and frbr:isEmbodiedIn. There may be other properties from the bib record that could be attached, but we shouldn't fret about the existence of the Expression if there aren't. > My personal opinion is that any RDF representation of FRBR, owing to > RDF's open world assumption, should be able to account for any entity > being missing from the initial point of modeling -- if all you "know" > about is the Item and the Work (or Expression or whatever), then we > should be able to go with that and patch in the blank holes later. I agree that something is better than nothing. I'm just trying to give Karen some sensible options for doing it now. Jeff > > -Ross.
Received on Wednesday, 15 September 2010 18:56:30 UTC