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