W3C home > Mailing lists > Public > public-prov-wg@w3.org > November 2011

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

From: Timothy Lebo <lebot@rpi.edu>
Date: Sun, 6 Nov 2011 16:42:34 -0500
Cc: "'Luc Moreau'" <L.Moreau@ecs.soton.ac.uk>, "'Jim McCusker'" <mccusj@rpi.edu>, "'Provenance Working Group WG'" <public-prov-wg@w3.org>
Message-Id: <78425A94-9C28-42A9-B48B-DB90646E92A6@rpi.edu>
To: "Stephan Zednik" <zednis@rpi.edu>

On Nov 6, 2011, at 12:22 PM, Stephan Zednik wrote:

> Does this imply that all qualifiers must be typed literals?


Also very scary. Thanks for pointing out the general case, Stephan.

-Tim


> 
> --Stephan
> 
> -----Original Message-----
> From: Luc Moreau [mailto:L.Moreau@ecs.soton.ac.uk] 
> Sent: Sunday, November 06, 2011 10:00 AM
> To: Jim McCusker
> Cc: Provenance Working Group WG
> Subject: Re: PROV-ISSUE-142 (Tlebo): Can roles only be Literals? [Data
> Model]
> 
> Hi Jim,
> 
> It is intentionally that we use typed literals here, and not identifiers.
> 
> If we allow identifiers, then in effect we would have introduced a new
> relation;  it would be better defined as prov-dm relation, rather than
> hidden in a qualifier.
> 
> What's wrong with "the role of president"  here?
> 
> Luc
> 
> On 06/11/11 15:19, Jim McCusker wrote:
>> 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
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
Received on Sunday, 6 November 2011 21:44:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:03 UTC