Print

Print


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