Print

Print


Actually, I figured out what would make it make sense to me:

either you have:

work1 bf:contributor <URI for contributor>

OR:

work1 bf:contribution <blank node or named node, call it B> .
B bf:contributor <URI for contributor> ;
    bf:relationshipID <URI for relationship> .

In other words, I'd be more comfortable with a separate property for the 
node containing contributor and relationship, rather than using one 
property for both cases. I do think this is a modeling issue.

kc

On 1/27/14, 2:24 PM, Simon Spero wrote:
>
> Karen-
> There are no blank nodes in either example. relationship1 is the name 
> of a plain old non-blank node.
>
> The issue with the second case is that it is taking information that 
> is taking information that is specializing the contributor 
> relationship/property and sticking it in a new object with the value.
>
> The range (value) of the contributor property is thus either a 
> Person/Agent, or a Relationship object.
> It is difficult to come up with a name for this combined type, which 
> is often a sign of a modeling issue.
>
> A better way to deal with this situation is to define a sub property 
> of contributor that denotes the specific relationship. If one wishes 
> to record extra information about the property, then you can add 
> assertions to the property URI (for example, a natural language 
> description).
>
> Simon
>
> On Jan 27, 2014 3:58 PM, "Karen Coyle" <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
> > so let's go back to the original example from the MARC document, 
> which is what I'm curious about, and take the easier example. The 
> document gives two possible BIBFRAME fragments:
> >
> > #1
> >
> > work1  a  bf:Work;
> >             bf:contributor  <URI for illustrator's name>.
> >
> > #2
> >
> > work1 a bf:Work
> >             bf:contributor   relationship1.
> > relationship1  a  bf:Related;
> >             bf:relationshipID id.loc.gov/vocabulary/relators/ill 
> <http://id.loc.gov/vocabulary/relators/ill>;
> >             bf:identifier  <URI for illustrator's name>.
> >
> >
> > I have no problem with #1. #2 puzzles me, though. In this case, 
> "relationship1" is probably a blank node, so I"m going to remove the 
> semantics from that:
> >
> > work1 a bf:Work ;
> >             bf:contributor   _b123.
> > _b123  a  bf:Related;
> >
> >             bf:relationshipID id.loc.gov/vocabulary/relators/ill 
> <http://id.loc.gov/vocabulary/relators/ill>;
> >             bf:identifier  <URI for illustrator's name>.
> >
> > I'm still trying to understand what this might mean.  I don't find 
> bf:Related defined (there is a class Relationship that appears with 
> http://bibframe.org/vocab/Related.html). But the blank node should 
> have the semantics of the object of bf:contributor. To say that the 
> object of bf:contributor is a relationship doesn't seem right, 
> especially when the node contains an Agent and a Relationship (I'm 
> assuming that relationshipID is a property of class Relationship). How 
> does this result in the statement:
> >
> >     work1 has illustrator <URI for illustrator>  [and NOT for 
> illustrator's name, btw]
> >
> > Instead, it seems to say:
> >
> >     work1 has a contributor and the contributor is a relationship 
> between "ill" and "<URI for illustrator>".
> >
> > In other words, I don't see how this states that the <URI for 
> illustrator> has relationship "ill" with work1.
> >
> > I hope someone else sees it clearly.
> >
> > kc
> >
> >
> >
> >
> > --
> > Karen Coyle
> > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net
> > m: 1-510-435-8234
> > skype: kcoylenet
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet