Fwd: Re: Intentions of XMP

_____________Original message ____________
Subject:	Re: Intentions of XMP
Sender:	ext Alan Lillich <alillich@adobe.com>
Date:		Thu, 26 Sep 2002 19:30:59 +0300

on 9/26/02 8:24 AM, Patrick Stickler at patrick.stickler@nokia.com wrote:

> Thanks very much for your clarifications, Alan. I hope you don't mind my
> forwarding them to the RDF Core working group.

I guess not, hoping folks don't take things out of context. I do (casually)
follow www-rdf-interest but not w3c-rdfcore-wg. Is the latter restricted to
members of the WG? Andrew Salop and Arno Gourdol are the Adobe reps.

> So when it comes down to comparing two values, applications are not basing
> equality for e.g. dates on string comparison, but on the values denoted by
> those strings. Right.

Yes, applications need to be aware of the intended data type. For dates in
particular that seems the only reasonable approach, since ISO 8601 allows
either UTC or zoned encoding of the same moment.

> Perhaps a clearer, more mnemonic way to ask this question would be, do the
> literal values of the following two properties mean the same thing to XMP
> applications? Would they be considered to carry equivalent semantics in both
> cases?
> 
> <xmp:CreateDate>2002-09-25T11:36:07Z</xmp:CreateDate>
> <dc:title>2002-09-25T11:36:07Z</dc:title>

No and no. Semantics in XMP are attached to the property not the literal
string in the stored RDF. The first is an ISO 8601 formatted date, the
second is a string that happens to look like an ISO 8601 formatted date.

Also, these 2 dates would be considered the same:

> <xmp:CreateDate>2002-09-25T11:36:07Z</xmp:CreateDate>
> <xmp:CreateDate>2002-09-25T13:36:07+02:00</xmp:CreateDate>


The Adobe XMP toolkit does not currently allow denoted data types. But if it
did this would be to define the representation and not the fundamental type.
That is, xmp:CreateDate will always be a date. Right now it must be ISO 8601
and nothing else. I can imagine some utility in using rdf:type and rdf:value
nodes to support other formats. From a practical point of view though this
would be a royal pain and unreliable. How can we be sure to be able to
convert an arbitrary encoding?

hope this helps,
Alan Lillich
Adobe Systems, alillich@adobe.com

Received on Thursday, 26 September 2002 12:41:25 UTC