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

Hi Luc, Curt:

I like this solution, as it keeps the dm abstract while improving
interoperability.

If we go for this solution, then maybe we should add this as an
informative comment in the DM. Also, can we align PROV-XML, prov-o and
maybe prov-n so that they both use URIs. This would help with
interoprability.

If we chose not to do it for prov-n, then I think it's ok because this
is supposed to be a "human readable" syntax.

Thanks
Paul

On Wed, Sep 12, 2012 at 3:37 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
> 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.
>
> Luc
>
> 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 14:31:04 UTC