Oh, now I'm re-reading this and I see your example in a different light. 
Let me see if I get it:

On 5/16/13 10:31 AM, Karen Coyle wrote:
> On 5/16/13 8:08 AM, Owen Stephens wrote:
>> You are correct in the direction of the relationship, but the thing I was really getting at was the additional layer. SCoRO actually does something more like:
>> PersonB -> hasRole -> Role1
>> Role1 -> isAuthorOf -> BookA

This works if Role1 is a unique URI, am I right? You've just added one 
step of indirection. But it isn't re-usable, if I'm not mistaken -- it 
only can be used once, to link PersonB to BookA. Therefore, why not:

PersonB -> isAuthorOf -> BookA

What advantage do you get from the extra triple? (Or has my brain melted 
down?) It still doesn't accommodate a string as role.


>> Which is not dissimilar to what Tom was proposing I think?
> Actually, I don't think that's quite it. What is "Role1" in this case? 
> It can't be "editor" or some URI for editor, because then you'd be saying:
> "John hasRole editor"
> "editor is author of BookA"
> Unless "editor" is some unique ID, you haven't connected these 
> together. If it is a unique id, then it doesn't make sense as a role. 
> It's more like "has specific relationship to" or something like that. 
> Looking at what SCoRO does shows how far you have to go to make a 
> clear connection. First, in their turtle (which is deceptively concise):
> :Shottona foaf:Person ; foaf:name "David Shotton" ;
>     scoro:hasORCID "0000-0001-5506-523X" ;
>     pro:holdsRoleInTime [ a pro:RoleInTime ;
>        pro:withRole scoro:author , scoro:senior-author ;
>        scoro:relatesToPublication:Adventures] ;
> This says that:
> - Shotton is a person
> - Shotton has name "David Shotton"
> - Shotton has ORCID ...
> - ShottonholdsRoleInTime Role1
> - Role1 is a RoleInTime
> -Role1withRole scoro:author
> -Role1  withRole scoro:senior-author
> - Role1 relatesToPublication (URI)Adventures
> Each role/publication relationship gets its own identifier in this 
> scenario. However, this doesn't give you a role in the bibliographic 
> entity. In fact, you have a gap there to be filled:
> BibEntity1 -> ? -> Shotton
> There's no relationship here, because the role, which is the 
> relationship, is a property of the person, not the bibliographic 
> entity. Let's say that you do what SCoRO does, and use "dc:creator" as 
> a generic relationship between the bibliographic entity and the person.
> BibEntity1 -> dc:creator -> Shotton
> Then the role has to be found NOT by querying simply for Shotton, but 
> by querying Shotton + relatesToPublication, returning all values for 
> "withRole", which in this case is "author" and "senior-author." This 
> means that if you don't query for the role, you don't know what the 
> relationship is between Shotton and BibEntity1. It also begs the 
> question of "roles" like being the subject of, or the owner of, 
> something. SCoRO is only concerned with creators so they don't cover 
> these other cases.
>>> It still doesn't solve our problem of roles without URIs, which cannot be in that middle position in the triple.
>> SCoRO itself limits the types of relationship that can be used, but the structure would allow you to adopt something closer to Tom's proposal
>> Owen
> Yes, because role in SCoRO is an object and not a predicate, you could 
> use text instead of a URI. I believe this is all very similar to the 
> example I gave with blank nodes, although this solution allows one to 
> link all publications to a single Person (or corporation, etc.) 
> identity. I wouldn't, however, consider it "lightweight." :-)
> kc
> -- 
> Karen Coyle
> [log in to unmask]
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

Karen Coyle
[log in to unmask]
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet