Re: PROV-ISSUE-142 (Tlebo): Can roles only be Literals? [Data Model]

Hi Jim,
presidentRole involves leaderRole?
I was going to say act_as, but we are relating the roles, not the people
who play them.

Also, if you want to create hierarchies of Roles, an alternative modeling
could be
to create President and Leader as a subclasses of role and then link an
instance
of those classes to Barack Obama.

Thanks,
Daniel
2011/11/6 Jim McCusker <mccusj@rpi.edu>

> Daniel, Luc,
>
> How would you relate "presidentRole" to "leaderRole"?
>
> Jim
>
> On Sun, Nov 6, 2011 at 12:02 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>
> wrote:
> > Hi Daniel,
> > That's seems fine modelling and prov-dm supports it.
> > Luc
> >
> > On 06/11/11 16:14, Daniel Garijo wrote:
> >
> > Hi Jim,
> > what was rejected is Roles being subclasses of Entities.
> > Roles can still be classes...
> >
> > In your example, I would make "presidentRole" and instance
> > of class Role and then link it to the entity "Barack Obama".
> >
> > Best,
> > Daniel
> >
> > 2011/11/6 Jim McCusker <mccusj@rpi.edu>
> >>
> >> Make Roles resources like Entities. Classes of Roles (Creator,
> >> Publisher, PrincipleInvestigator) are instantiated for each Entity. Of
> >> course, this is rather similar to what's been rejected (?), but is
> >> still the best choice, IMO. This would be, for instance, "Barack
> >> Obama's role as president", as opposed to "the role of president",
> >> which would be a class.
> >>
> >> Role could also be an extension of skos:Concept and allow you to
> >> express "the role of president" directly without custom instantiation.
> >>
> >> Jim
> >>
> >> On Sun, Nov 6, 2011 at 8:38 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>
> >> wrote:
> >> > Ok, so, what's alternative suggestion ?
> >> >
> >> > Professor Luc Moreau
> >> > Electronics and Computer Science
> >> > University of Southampton
> >> > Southampton SO17 1BJ
> >> > United Kingdom
> >> >
> >> >
> >> > On 6 Nov 2011, at 12:59, "Jim McCusker" <mccusj@rpi.edu> wrote:
> >> >
> >> >> This is a misunderstanding of a URI literal versus URI resource. When
> >> >> a URI resource is used, it can link to that resource when it has
> >> >> assertions made about it. This is not possible or intended with URI
> >> >> literals.
> >> >>
> >> >> Jim
> >> >>
> >> >> On Sun, Nov 6, 2011 at 2:36 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk
> >
> >> >> wrote:
> >> >>> Hi Tim,
> >> >>>
> >> >>> But doesn't this include URIs by means of typed literals?
> >> >>>
> >> >>> Professor Luc Moreau
> >> >>> Electronics and Computer Science
> >> >>> University of Southampton
> >> >>> Southampton SO17 1BJ
> >> >>> United Kingdom
> >> >>>
> >> >>> On 6 Nov 2011, at 01:20, "Provenance Working Group Issue Tracker"
> >> >>> <sysbot+tracker@w3.org> wrote:
> >> >>>
> >> >>>>
> >> >>>> PROV-ISSUE-142 (Tlebo): Can roles only be Literals? [Data Model]
> >> >>>>
> >> >>>> http://www.w3.org/2011/prov/track/issues/142
> >> >>>>
> >> >>>> Raised by: Timothy Lebo
> >> >>>> On product: Data Model
> >> >>>>
> >> >>>> prov-dm, 5.5.1 Qualifier:
> >> >>>>
> >> >>>> "The value associated with a role attribute must be conformant with
> >> >>>> Literal."
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Will this prevent PROV-O from using URIs to cite roles?
> >> >>>>
> >> >>>> Restricting roles to literals will be severely limiting for PROV-O
> >> >>>> and semantic web applications, since literals cannot be described
> or served
> >> >>>> as linked data, and thus consumers will be unable to determine more
> >> >>>> information about what the role means.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Jim McCusker
> >> >> Programmer Analyst
> >> >> Krauthammer Lab, Pathology Informatics
> >> >> Yale School of Medicine
> >> >> james.mccusker@yale.edu | (203) 785-6330
> >> >> http://krauthammerlab.med.yale.edu
> >> >>
> >> >> PhD Student
> >> >> Tetherless World Constellation
> >> >> Rensselaer Polytechnic Institute
> >> >> mccusj@cs.rpi.edu
> >> >> http://tw.rpi.edu
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Jim McCusker
> >> Programmer Analyst
> >> Krauthammer Lab, Pathology Informatics
> >> Yale School of Medicine
> >> james.mccusker@yale.edu | (203) 785-6330
> >> http://krauthammerlab.med.yale.edu
> >>
> >> PhD Student
> >> Tetherless World Constellation
> >> Rensselaer Polytechnic Institute
> >> mccusj@cs.rpi.edu
> >> http://tw.rpi.edu
> >>
> >
> >
>
>
>
> --
> Jim McCusker
> Programmer Analyst
> Krauthammer Lab, Pathology Informatics
> Yale School of Medicine
> james.mccusker@yale.edu | (203) 785-6330
> http://krauthammerlab.med.yale.edu
>
> PhD Student
> Tetherless World Constellation
> Rensselaer Polytechnic Institute
> mccusj@cs.rpi.edu
> http://tw.rpi.edu
>
>