First, since I have not posted to this list before, let me introduce myself.
I am Robert Charles Anderson, one of the "Principal Members" of the Lexicon
Working Group.  Everybody in the LWG had both genealogical and technological
skills, in my case weighted more toward the former than the latter, although
I did learn a great deal about data modelling during the four years the
group worked together.

I'll try to answer the first of Hans's questions, and maybe that will
clarify some of the later questions as well.  As an example, let us say we
are working with a recorded deed, in a situation where the original deed
does not survive, or at least we don't know where it is.  Then the recorded
deed is the SOURCE.  If I create a written (paper) abstract of that deed,
then that is one REPRESENTATION.  Then perhaps I go back to the courthouse
with my digital camera and take a photograph of that same deed, and now I
have a second REPRESENTATION.  And then I make a complete transcript, as a
Word document, of the deed, and now I have a third.

All three of these might end up in electronic form, but the abstract is
still a paper document, and could have a Physical-File-Code.  A photographic
copy of the deed, not in digital form, would be another REPRESENTATION of
the same SOURCE, and could also have a Physical-File-Code.

A second example of this would be a photograph of the family picnic on July
4th of 1902, which your grandmother gave you when you were young.  This
would be the SOURCE in this instance.  A restored version of the photo would
be a REPRESENTATION, as would a digitized and stored version.

To answer two of the sub-parts of your first question:

"a photograph in my file cabinet" may be a SOURCE or a REPRESENTATION
depending on its pedigree.

REPRESENTATIONs are not "only encodings of the source that can be stored and
transmitted" electronically.

Hope this helps.

RCA



----- Original Message -----
From: Hans Fugal <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 15, 2002 10:41 PM
Subject: [gdmxml] Representation


> After about 5 weeks I'm finally getting back to this.  I hope everyone
> else's minds are less clouded over than my own. :)
>
> I have addressed all the elements of the evidence submodel to my liking
> with the exception of representation.  I have a few questions for the
> members of the LWG out there, as well as anyone who understands the
> representation and representation-type elements. (and anyone else, as
> well!)
>
> REPRESENTATION
> --------------
> source-id (FK)
> representation-type-id (FK)
> physical-file-code
> medium
> content (Text or multimedia)
> comments
>
> REPRESENTATION-TYPE
> -------------------
> representation-type-id (PK)
> representation-type-name
>
> My questions are:
> - First, what is a REPRESENTATION in the context of the GDM?
>   Specifically, how does it relate to a digital encoding and physical
>   representation? Is a photograph in my file cabinet a REPRESENTATION or
>   is that a SOURCE in and of itself? Or are representations only
>   encodings of the source that can be stored and transmitted? Most of
>   the rest of the questions stem from this one.
> - What is the difference between representation-type and medium?
> - Physical-file-code combined with a physical representation would seem
>   to be just another source that should be documented as such.
>
> And a few comments:
> - "One REPRESENTATION is a manifestation of one SOURCE" - so I will nest
>   representation in source in the xml format.
> - there are pre-existing standards for defining the location of things
>   in 'cyberspace' and the type and encoding of the data: URIs and
>   mime-types, respectively. I think it would be appropriate to bring
>   those into play if appropriate. One consideration in doing this of
>   course is that local URIs will only be valid on the local system (but
>   then so would any way of citing a file on the local system).
> - When content is a text transcription, it may be very appropriate to
>   use TEI for encoding the text.
> - When we wish to communicate an image or other binary format we could
>   mime-encode it just as we do with email attachments.
>
> <hans/>
> --
> "Everybody is talking about the weather but nobody does anything about
it."
>         -- Mark Twain
>
> _______________________________________________
> gdmxml mailing list
> [EMAIL PROTECTED]
> http://fugal.net/cgi-bin/mailman/listinfo/gdmxml


_______________________________________________
gdmxml mailing list
[EMAIL PROTECTED]
http://fugal.net/cgi-bin/mailman/listinfo/gdmxml

Reply via email to