Hi Karen, I think we're talking about different things (which, admittedly, is probably my fault).
I thought you wanted something to be able to compare, say, a WEMI resource to a resource that wasn't structured as WEMI: a BIBO citation or a MARC or MODS resource (modeled in something that keeps the FRBR-related stuff together). You mentioned something about not being able to relate FRBR entities to non-FRBR entities and, given that our legacy resources are going to be modeled in all sorts of ways, the property I created was an attempt to address that. In OL, you can create FRBR Works pretty easily (it seems): it's the rest of it that's challenging. So if you wanted to punt on that at first and model the editions as bibo:Books (which are FRBR averse, since they schmush a bunch of properties that would be scattered across the entities onto one resource), ov:commonManifestation would let you relate the bibo:Book to the frbr entities we *do* know (Work and, possibly, eventually, Expression and Manifestation - and for physical libraries, Items). Citations (and MARC) almost always contain (at least) one manifestation in them. This property is using that implied manifestation as the "link" between the FRBR and non-FRBR data. Basically, this is a response to: "Could this be generalized to work beyond FRBR? I'm thinking that it might be useful to link, for example, a MARC record to a FRBR work entity. Obviously it would be better to have a link that tells you HOW the two things are related/associated, but I can well imagine many situations where something more general will be useful." My argument is that HOW is because these two things are describing a common manifestation (we could take this further and give it a superproperty of commonFRBREntity, to make it more extensible), which 99% of cases with our current bibliographic data would be the case. Does that explain it a bit better? Thanks! -Ross. On Sat, Dec 4, 2010 at 1:04 PM, Karen Coyle <[email protected]> wrote: > Hi, Ross. Me just getting back from travels, a bit behind. > > So... > > but isn't it the case that the manifestations are different? That's > the one thing we know, because they have different data (publisher, > date, pagination, etc.). So unfortunately I do think that we are > having to say that these are (Probably?) the same work/expression. > > BTW, I saw some great slides at SWIB (Semantic Web in Bibliotheken) in > Cologne, and I will ask Alexander Haffner to put them up online, even > though they are in German -- he has a great sequence where he shows > how they create WEMI instances, then merge on W and E after the fact > (and it includes the possible solution to my identifier problem). > > kc > > Quoting Ross Singer <[email protected]>: > >> Karen, I've been thinking about this some more (oddly, on another day >> where I have to chaparone another of my son's field trips) and rather >> than claiming that these two resources are describing same endeavour >> (which, I fear, will get too abstract), it might make more sense to >> say that both resources share the same manifestation (which, I think >> is what we really mean, and care about, anyway). >> >> So, instead of endeavourRelation, what about: >> >> ov:commonManifestation >> domain: rdfs:Resource >> range: rdfs:Resource >> >> This property indicates that both resources are describing a >> bibliographic endeavour that implicitly contains the same >> manifestation. It is intended to be used to help relate FRBR entities >> to bibliographic descriptions that are not modeled in FRBR (or two >> bibliographic descriptions that are not modeled in FRBR) but contains >> data that refers to the same manifestation. >> >> Obviously the description could use some editing, but does the general >> idea make sense? >> >> Thanks! >> -Ross. >> >> On Tue, Nov 16, 2010 at 5:54 AM, Karen Coyle <[email protected]> wrote: >>> Ross, your associatedEntity description reads: >>> >>> "This property is used to relate two FRBR Endeavours/entities >>> (http://vocab.org/frbr/core.html#Endeavour) together even if the >>> entire Work-Expression-Manifestation-Item hierarchy does not exist. >>> For example, it could be used to relate a frbr:Work to a >>> frbr:Manifestation without the need of a frbr:Expression to link them >>> through. The property is symmetric (if a <_:work> ov:associatedEntity >>> <_:item> then <_:item> ov:associatedEntity <_:work>. It is not >>> transitive (items may be associated with the same work but not be in >>> the same WEMI chain, for example)." >>> >>> Could this be generalized to work beyond FRBR? I'm thinking that it >>> might be useful to link, for example, a MARC record to a FRBR work >>> entity. Obviously it would be better to have a link that tells you HOW >>> the two things are related/associated, but I can well imagine many >>> situations where something more general will be useful. So maybe >>> something like: >>> >>> "This property is used to relate two bibliographic entities (such as >>> as subclasses of FRBR Endeavor; >>> http://vocab.org/frbr/core.html#Endeavour) together even if they are >>> not entities of the same type. For example, a bibliographic entity in >>> a MARC record could be associated with any FRBR entity; or FRBR >>> entities could be related even though where entire >>> Work-Expression-Manifestation-Item hierarchy does not exist, e.g. to >>> relate a frbr:Work to a frbr:Manifestation without the need of a >>> frbr:Expression to link them through. The property is symmetric (if a >>> <_:work> ov:associatedEntity <_:item> then <_:item> >>> ov:associatedEntity <_:work>. It is not transitive (items may be >>> associated with the same work but not be in the same WEMI chain, for >>> example)." >>> >>> Or is that just too generic? >>> >>> kc >>> >>> Quoting Ross Singer <[email protected]>: >>> >>>> Ok, I just created: >>>> http://open.vocab.org/terms/associatedEntity >>>> >>>> which links two frbr:Endeavours together symmetrically. >>>> >>>> -Ross. >>>> >>>> On Wed, Nov 10, 2010 at 11:07 AM, Ross Singer >>>> <[email protected]> wrote: >>>>> Karen, Erik is right that: >>>>> >>>>> <http://openlibrary.org/works/OL262758W/> >>>>> frbr:Manifestation <http://openlibrary.org/books/OL10236414M/>, >>>>> <http://openlibrary.org/books/OL10636839M/>, >>>>> <http://openlibrary.org/books/OL10681592M/>, >>>>> <http://openlibrary.org/books/OL10686044M/>, >>>>> <http://openlibrary.org/books/OL13268284M/>, >>>>> <http://openlibrary.org/books/OL1937352M/>, >>>>> <http://openlibrary.org/books/OL20352933M/>, >>>>> <http://openlibrary.org/books/OL21968605M/>, >>>>> <http://openlibrary.org/books/OL22836306M/>, >>>>> <http://openlibrary.org/books/OL24374464M/>, >>>>> <http://openlibrary.org/books/OL24375966M/>, >>>>> <http://openlibrary.org/books/OL3969888M/>, >>>>> <http://openlibrary.org/books/OL5416735M/>, >>>>> <http://openlibrary.org/books/OL5526619M/>, >>>>> <http://openlibrary.org/books/OL6363476M/>, >>>>> <http://openlibrary.org/books/OL7261137M/>, >>>>> <http://openlibrary.org/books/OL7262049M/>, >>>>> <http://openlibrary.org/books/OL7262683M/>, >>>>> <http://openlibrary.org/books/OL7603172M/>, >>>>> <http://openlibrary.org/books/OL7851787M/> ; >>>>> a frbr:Work . >>>>> >>>>> isn't going to work (frbr:Manifestation being a class, not a >>>>> property). While you're right that there is no (current) obvious way >>>>> to go jump over frbr:Entities in the WEMI chain, there are some >>>>> options here. >>>>> >>>>> For the version of the OL data that we host in the Platform, we're >>>>> using dcterms:hasVersion/isVersionOf. >>>>> >>>>> 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] >> > > > > -- > 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]
