Thanks Nate! On Tue, Sep 16, 2014 at 2:11 PM, Trail, Nate <[log in to unmask]> wrote: > • musicVersion and other properties without a domain: we are usually > uncertain or agnostic as to whether it belongs on Work or Instance, as you > guessed, and so we left it unconstrained. We don’t really mean that it > could be on any Class, like Person, but that’s a side effect of leaving the > domain blank. > Yup, and (sorry for not being clear in the original mail) the same rationale as other literals for why it's a literal not another Work/Instance? Eg otherEdition is a relationship, and this seems like the musical equivalent? > • Ideally, treatySignator would be a bf:Person or really a government > body, but the data from MARC is going to be stringy. This is yet another > example where if we had our druthers, we’d have a string version of a > property for legacy data, and a uri version for born bf: data. > We need to get you a druthers provider :) What about treatySignator domain bf:Agent (so as to be neutral about organization/person) with a label of the string content? > • bf:agent : often, there is a name listed in the 7xx fields, but no > relationship stated, nor type of material, so you can’t guess at the role > the person plays with respect to that resource > Gotcha :( Or likely even whether it should be the Work or the Instance. • * bf:edition : MARC 250$a bf:editionResponsibility 250$b bf:otherEdition > MARC 775. > o The first two describe this edition, the otherEdition points to > a different resource: > o BF edition and responsibility: : > http://bibframe.org/tools/compare/bibid/7810461 > o bfotherEdition: > http://bibframe.org/tools/compare/bibid/11346685 > 250$a and $b I [believe I] understand. And the discussion that there's no need to merge them as the bf:editionResponsibility must always belong to the bf:edition ... as any other edition must be a new _bf:Instance_ so each Instance can only ever have one of each. But then bf:otherEdition should be a relationship between Instances, not between Works? Rob --- Range/Domain --- > > * bf:dissertationInstitution has a range of bf:Agent, not bf:Institution. > Are there really people that give out dissertations (and how much do they > cost? :D) > > * bf:edition (and bf:editionResponsibility, which looks like a Note) has a > domain of Instance, as expected from the Provider discussion that different > editions (and hence dates) must be different Instances. However, > bf:otherEdition has domain and range of bf:Work. This seems like a mistake? > > * Relatedly, bf:musicVersion has a range of Literal and no domain. This > seems like it should be Work or Instance? > * And similarly, bf:treatySignator has a range of Literal and no domain. > Seems like it should be a range of bf:Person? > > --- No Semantics --- > > * bf:agent doesn't seem to say anything beyond "Here is an agent somehow > related to this resource", and has no domain. Also, afaict, it has no > sub-properties. Can anyone shed some light on what the meaning of the > relationship is, and thus when a producer would create it and what a > consumer would do with it? > * bf:event is the same as bf:agent. > * bf:place used to exist, but no longer ... should agent and event also be > deleted? (temporal and topic never existed) > > * bf:relatedInstance seems to only have the semantics of relatedTo, but > with specific range and domain. Why would a consumer/producer use this > instead of relatedTo? > * Ditto bf:relatedWork > > * bf:legalDate seems to have the description of Date of a work that's > legal in nature, or the date a treaty was signed, or the date a law went > into effect. This seems so indistinct to the point of being worthless? > > --- Inconsistency --- > > * bf:originPlace, bf:originDate ... but bf:Provider, and the previous > discussion about providerName and providerDate. So when its an Instance, > the event gets its own resource, but when its a Work, it doesn't? > > Thanks! > > Rob > > -- > Rob Sanderson > Technology Collaboration Facilitator > Digital Library Systems and Services > Stanford, CA 94305 > -- Rob Sanderson Technology Collaboration Facilitator Digital Library Systems and Services Stanford, CA 94305