Thanks for the history. That makes sense. And thanks for looking over our
current approach. And sure, I'm interested in whatever discussion develops
around 3D in METS.
At 05:24 PM 12/4/2001 -0500, you wrote:
>In our original planning meeting for METS back in February,
>we intentionally and explicitly said that we were not going
>to try to handle 3D objects in this first go-round. So,
>as you've recognized, serious support for identifying a
>portion of a 3D data file is lacking. We are, I believe,
>going to be declaring version 1 of METS finished and
>hand it off to DLF for review soon. At the same time,
>we are forming an editorial board to engage in further
>development of the METS schema, and to work on things like
>extension schema. When this happens (early next year), I think
>it will be time to revisit the 'no 3D, no GIS' decision, and
>think about how we might add support for those.
>In the interim, I think you're approach of separating
>out the QTVR parameters into a separate XML file and
>leaping from the <div> into that file is as good a solution
>as any. In the future, when METS supports 3D, such information
>can be relocated from a separate file into a METS structmap.
>You *do* realize that as the first person to raise the
>3D issue on the list, you just volunteered to help figure
>out how to modify METS to support 3D objects? :)
>----- Original Message -----
>From: Bill Parod <[log in to unmask]>
>Date: Tuesday, December 4, 2001 1:56 pm
>Subject: [METS] Extensions to <area>?
> > I'm new to this list, so pardon me if this has been covered.
> > Are there ways or plans to extend <area> to handle 3D references?
> > For example with archeological sites, having a 3D spatial profile, the
> > <structMap> works nicely for representing
> > site/building/room/surface/detailhierarchies. And xml and image
> > files are nicely referenced from each <div>
> > with <fptr>. In our case, each building <div> also has a QTVR file
> > representing its 3D space. The problem comes when referring to a
> > specificregion of that QTVR from room, surface, or detail <div>
> > levels. The natural
> > way to do it would be to use <area> to hold specific node_id,
> > pan_angle,tilt_angle, and field_of_view parameters on the QTVR
> > file. But I don't see
> > how to use <area> to accommodate these particular QTVR parameters, or
> > indeed any other 3D parameters.
> > What we'll probably do is package all QTVR view parameters in an
> > xml file
> > and refer to specific "views" via <area ..BETYPE="IDREF"/>. Would
> > that be
> > the right way to handle this? Is there a better way? These view
> > parametersaren't global to the QTVR file but rather unique to
> > specific views. So
> > holding them solely in <area> seems truer to spirit, say if <area>
> > wereextensible like the metadata sections.
> > Thanks for any suggestions,
> > Bill Parod
> > Northwestern University, Evanston, IL. USA
> > [log in to unmask]
Northwestern University, Evanston, IL. USA
[log in to unmask]