Re: Intentions of XMP

_____________Original message ____________
Subject:	Re: Intentions of XMP
Sender:	ext Alan Lillich <alillich@adobe.com>
Date:		Thu, 26 Sep 2002 19:53:33 +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.

	Who? Us? Never. ;-)

 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.

	Yes. w3c-rdfcore-wg is the 'closed' discussion list of the
	RDF Core WG, though its archives can be viewed publically
	on the W3C website.
 
> 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>

	Thanks. That clarifies alot.

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?

	Well, certainly not any arbitrary encodings, but I could envision
	a modular approach where factories for custom datatypes
	could be plugged into XMP to provide for mapping between
	other lexical encodings and the native datatypes supported	
	by XMP. In that way, such encodings would be declared
	and defined in terms of the core XMP framework while
	providing alot of extensibility. Anyway, just thinking out loud...

hope this helps,

	Very much. Thanks,

	Patrick

Alan Lillich
Adobe Systems, alillich@adobe.com

Received on Thursday, 26 September 2002 13:08:49 UTC