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

Hi all,

 

Comment below.

 

From: Luc Moreau [mailto:L.Moreau@ecs.soton.ac.uk] 
Sent: Sunday, November 06, 2011 10:02 AM
To: Daniel Garijo
Cc: Jim McCusker; Provenance Working Group WG
Subject: Re: PROV-ISSUE-142 (Tlebo): Can roles only be Literals? [Data
Model]

 

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... 

The statement that qualifiers must be typed literals seems to contradict the
statement that roles can still be classes.

What's even more important to me, it seems we are implying that all
qualifiers should be typed literals.  Qualifiers are designated an extension
point in the prov-DM, but we are now limiting these extensions to being just
Literals.

I presume the idea of 'extension' is that there would be a prov:qualifer
DataTypeProperty in prov-o and users would be encouraged to define
domain-specific sub-properties?  If a user wishes to define a
domain-specific objectProperty for use in Usage or Generation, etc., then
this would not be an extension of a qualifier?

Is time information on Usage, Generation, etc. a defined specialization of
qualifier?  Are we happy with limiting our time statements to Literals?

--Stephan


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 <mailto:sysbot%2Btracker@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 <tel:%28203%29%20785-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 <tel:%28203%29%20785-6330> 
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu