[topicmapmail] Should resourceData have a MIME type?
Kal Ahmed
kal@techquila.com
Tue, 14 Jan 2003 09:57:19 +0000
On Tuesday 14 January 2003 04:39, Nikita Ogievetsky wrote:
> Kal wrote:
> > On Monday 13 January 2003 15:17, Nikita Ogievetsky wrote:
> > > Thinking about this issue again I must say that neither occurrence
> > > type, nor scope, nor variant (which is not there yet) are the prope=
r
>
> syntactical
>
> > > places
> > > for expressing resourceData MIME type.
> > > I am saying this because all off the above allow expressing propert=
ies
>
> of
>
> > > occurrence assertion. And MIME type is the property of the resource
>
> itself,
>
> > > not occurrence!
> >
> > Thats a good point. We discussed this on IRC and it seems that we are
> > converging on reification as the solution here. I agree with you that
> > what should be reified is the occurrence resource itself (if you have=
a
>
> resource
>
> > rather than resource data) or the resourceData element (if your data =
is
> > contained in-line).
> >
> > Of course, we should have PSIs for "resource-has-media-type" and for =
MIME
> > types in general.
>
> I like this. But I also wonder whether "class-instance" may be used her=
e.
> What are your reservations against it?
>
My reservation is linked to an issue recently discussed on this list - th=
at=20
different people have a different idea of what the "class-instance"=20
relationship means. I would prefer to see an explicit association type th=
at=20
could not be misinterpreted or used for other purposes.
> > We also discussed how this might be related to datatyping - it feels =
at
>
> least
>
> > as though data-typing is a similar issue and that a similar approach
>
> *might*
>
> > solve that too - although only for simple data types.
> >
> > In addition, it would appear that TMCL needs to take this into
>
> consideration
>
> > as it would be desirable to be able to constrain the media/data type =
of a
> > class of occurrences (e.g. all "Picture" occurrences must be a PNG, G=
IF
> > or JPG image; all "Age" occurrences must be media-type=3Dtext and
> > data-type=3Dinteger)
>
> That is an interesting idea. However this constraints should definitely=
be
> optional
> and customizable/extendable to allow for new MIME types as they arrive.
> (like SVG, for example)
> It is also interesting to keep a taxonomy of MIME types and have PSIs f=
or
> various image classes. For example:
> image->raster image->JPEG
> ->vector image->SVG
> xml ->SVG
>
> Than one can reference one of the MIME classes (or use DAML-like
> expressions)
> in the TMCL pattern rather than enumerating all applicable MIME types.
>
Presumably if one were to describe such classes in a topic map, then one =
could=20
use the topics that represent the classes in any TMCL pattern (e.g all=20
"Picture" occurrences must be in a "has-mediaType" association with any t=
opic=20
which plays the "format" role in a "mediaClass-format" role where "raster=
=20
image" plays the "mediaClass" role).
Cheers,
Kal
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy
e: kal@techquila.com
p: +44 7968 529531
w: www.techquila.com