On Wed, Nov 10, 2010 at 4:23 PM, Karen Coyle <[email protected]> wrote: Karen,
I think the property I just made (the ov:associatedEntity) does exactly what you want. A way to interpret it would be: "these entities are associated with each other in the same WEMI chain". It doesn't matter what they are (Work<->Item, Expression<->Item, Work<->Manifestation). Plus it's symmetrical, so if you just say that a <work> ov:associatedEntity <manifestation>, it's entailed that the <manifestation> ov:associatedEntity <work>. It's effectively doing the same thing as dcterms:hasVersion/isVersionOf without A) needing the explicit inverse relationship B) any semantics implied in the relationship/inverse. -Ross. > Thanks, Ross. > > I think the issue is that there isn't a way to describe the > manifestation as an object of the Work -- the manifestation needs to > be expressed as: > > URI4Manifestation a type frbr:Manifestation > URI4Manifestation workManifested URI4Work > > Without a reciprocal relationship, there isn't a way to say: > > URI4Work hasManifestation URI4Manifestation > > I was trying to describe the Manifestation with the Work "stripe", but > that isn't possible (without a new predicate, as Jonathan suggests). I > hesitate to mess too much with FRBR -- it's enough of a mess already, > and following it as best I can is a way (IMO) of showing whether it > can work or not. (I often think not.) > > I'll try another model, then maybe blog it and see what people have to > say. I also think that it's mainly hard to do this in RDF/XML so maybe > it's time for me to get adept at turtle. > >> >> For the version of the OL data that we host in the Platform, we're >> using dcterms:hasVersion/isVersionOf. > > Hmmm. I don't think that meets the definitions of the FRBR group 1 > entities in relation to each other. (I read the FRBR entities as > additive and hierarchical.) However, in some ways that makes more > sense to me than the FRBR entity relationships. It would allow you to > connect any entity to any other entity, not daisy-chaining them the > way FRBR requires you to. Another option would be to have them all be > related to a defined whole -- a defined "bibliographic entity." Note, > however, that the FRBR review group rejects that view (no, I don't > know what their reasoning is.) That is another possible model that > would be interesting to play with. > > kc > > >> >> http://api.talis.com/stores/openlibrary/meta?about=http://openlibrary.org/works/OL262758W&output=xml >> >> which isn't great, but the fact that both ends of the chain are >> frbr:Entities, we can infer the meaning. Even better would be add >> properties to http://open.vocab.org/: something like >> hasManifestation/manifestationOf. Perhaps even better would be to >> leverage http://vocab.org/frbr/core.html#Endeavour - associatedEntity >> as a property name perhaps? - that makes the modeling less >> complicated. That way we know that these are in the same WEMI chain, >> but we don't necessarily have to explicitly define /what/ it is in the >> relationship. >> >> -Ross. >> >> On Wed, Nov 10, 2010 at 9:28 AM, Karen Coyle <[email protected]> wrote: >>> Quoting Erik Hetzner <[email protected]>: >>> >>> >>>> What I meant to be getting at is that the rdf:type of the resources >>>> M1, M2, ... is (currently) workManifested, while the predicate linking >>>> W and M1, M2, ... is frbr:Manifestation. I think this is backwards; >>>> they rdf:type should be frbr:Manifestation, while the predicate should >>>> be workManifested. >>> >>> Thanks, Erik. From this conversation I have come to the realization >>> that there is no way to say: "this Work is Manifested as..." using >>> FRBR concepts. Instead, what I need to do is to create short "records" >>> for each manifestation that in effect each say: "manifests WorkX". I >>> don't think I can encapsulate the whole in a single rdf/xml unit >>> without creating some uber-structure that holds them together (which >>> would perhaps be a representation of FRBR Group 1 as a super-class, >>> something the the FRBR committee has rejected). I'll mock up something >>> and post it before I code it into the OL template. >>> >>> kc >>> >>>> >>>> As to which direction workManifested points, or its domain or range, I >>>> have no clue, but I assume you are correct here. >>>> >>>> best, Erik >>>> _______________________________________________ >>>> Ol-tech mailing list >>>> [email protected] >>>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >>>> To unsubscribe from this mailing list, send email to >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Karen Coyle >>> [email protected] http://kcoyle.net >>> ph: 1-510-540-7596 >>> m: 1-510-435-8234 >>> skype: kcoylenet >>> >>> _______________________________________________ >>> Ol-tech mailing list >>> [email protected] >>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >>> To unsubscribe from this mailing list, send email to >>> [email protected] >>> >> _______________________________________________ >> Ol-tech mailing list >> [email protected] >> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >> To unsubscribe from this mailing list, send email to >> [email protected] >> > > > > -- > Karen Coyle > [email protected] http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > > _______________________________________________ > Ol-tech mailing list > [email protected] > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > To unsubscribe from this mailing list, send email to > [email protected] > _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
