Print

Print


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:
[log in to unmask]" type="cite">
On 5/16/13 8:08 AM, Owen Stephens wrote:
[log in to unmask]" type="cite">
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.

kc



[log in to unmask]" type="cite">
[log in to unmask]" type="cite">

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):

:Shotton a 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 ...
- Shotton holdsRoleInTime Role1
- Role1 is a RoleInTime
- Role1 withRole 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.

[log in to unmask]" type="cite">
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] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

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