W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2012

Re: PROV-ISSUE-493: prov:type has type Value; valid values too general, include number, datetime, boolean, etc. [prov-dm]

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Wed, 12 Sep 2012 14:37:46 +0100
Message-ID: <EMEW3|15bc4bffc04e4f9a7d4f98e078cc1366o8BEbn08l.moreau|ecs.soton.ac.uk|5050902A.5030000@ecs.soton.ac.uk>
To: Curt Tilmes <Curt.Tilmes@nasa.gov>
CC: public-prov-wg@w3.org
Hi Curt,

I think prov-o does it already, since prov:type is encoded as the 
property rdf:type,
whose object is a resource (denoted by a URI).

So, I was thinking that it was up to the translator to convert type 
values to a type representation
that is suitable for the target representation. It seems to be aligned 
with your view.


On 09/12/2012 02:27 PM, Curt Tilmes wrote:
> I see your point -- by design the data model itself should be very
> general.
> Could we leave the DM itself open, but constrain the type of prov:type
> within PROV-O and/or PROV-XML?  In translating the examples where
> they have free text, we can simply impose a namespace to qualify the
> types in the more concrete representations.
> Curt
> On 09/12/2012 09:22 AM, Luc Moreau wrote:
>> Hi Curt and Stephan,
>> I am less certain about this change.
>> First, do you mean QName as in xsd:QName?
>> Why not use the prov:QualifiedName, which we already have (and can be
>> transformed into uris).
>> But then, why just prov:QualifiedName , and why not URI (xsd:anyURI)?
>> The reason why this was left unspecified is that PROV, intentionally,
>> refrained from defining
>> what a type system is, and therefore, a consequence, was that we didn't
>> define how to
>> represent a given type value.
>> Luc
>> On 09/12/2012 01:27 PM, Curt Tilmes wrote:
>>> I agree with Stephan.  The real reason for having prov:type at all is
>>> to encourage consistency.  Qnames encourage capturing semantic meaning
>>> beyond free text.
>>> The types we've defined
>>>    http://www.w3.org/TR/prov-dm/#term-attribute-type
>>> set a precedent for the type of types we think should fill prov:type,
>>> and the discussion of prov:type in the extensibility points section:
>>>    http://www.w3.org/TR/prov-dm/#extensibility-section
>>> shows examples defining new prov:types as qnames in other namespaces.
>>> This would require some rework of examples, but I think the change
>>> would be valuable in the long term.
>>> Curt
>>> On 09/12/2012 02:19 AM, Stephan Zednik wrote:
>>>> A quick reminder about this issue.
>>>> Looking at the PROV-DM document again I see a few examples where 
>>>> simple
>>>> non-qname strings are used for prov:type values.
>>>>   From example 21 
>>>> (http://www.w3.org/TR/prov-dm/#anexample-communication)
>>>> prov:type="fine paying, check writing, and mailing"
>>>> I think in most if not all of these cases the prov:type value could be
>>>> simplified to a qname.
>>>> I understand this change is significant due to the timing of the
>>>> suggestion, but I believe the benefit of making this change is
>>>> worthwhile.
>>>> Thanks,
>>>> --Stephan
>>>> On Sep 4, 2012, at 11:18 AM, Provenance Working Group Issue Tracker
>>>> <sysbot+tracker@w3.org <mailto:sysbot+tracker@w3.org>> wrote:
>>>>> PROV-ISSUE-493: prov:type has type Value; valid values too general,
>>>>> include number, datetime, boolean, etc. [prov-dm]
>>>>> http://www.w3.org/2011/prov/track/issues/493
>>>>> Raised by: Stephan Zednik
>>>>> On product: prov-dm
>>>>> The value of prov:type is a Value
>>>>> (http://www.w3.org/TR/prov-dm/#term-value) which has the following
>>>>> definition:
>>>>> A value ◊ is a constant such as a string, number, time, qualified
>>>>> name, IRI, and encoded binary data, whose interpretation is outside
>>>>> the scope of PROV. Values can occur in attribute-value pairs.
>>>>> Each kind of such values is called a datatype. Use of the following
>>>>> data types is recommended.
>>>>> The RDF-compatible [RDF-CONCEPTS] types, including those taken from
>>>>> the set of XML Schema Datatypes [XMLSCHEMA11-2];
>>>>> Qualified names introduced in this specification.
>>>>> The normative definitions of these datatypes are provided by their
>>>>> respective specifications.
>>>>> This means that numbers, datetimes, booleans, and unstructured 
>>>>> strings
>>>>> are valid values of prov:type.  The prov value section on RDF
>>>>> compliance also seems to suggest there should be a prov:type datatype
>>>>> property in prov-o, which to my knowledge does not currently exist.
>>>>> So my question is, are we ok with numbers, datetimes, booleans as
>>>>> valid values of prov:type?  All of the examples in the DM document
>>>>> appear to use qnames for values of prov:type.
>>>>> Second, is there support for a proposal to restrict values of
>>>>> prov:type to qnames?

Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
Received on Wednesday, 12 September 2012 13:38:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:18 UTC