RE: Overview of design decisions made creating stylesheet and sch ema for Artstor data

Kevin,

In an ideal world, there would already be a widely used person ontology and
the problem would be one of matching the information in ArtStor record to
the that ontology.  There are a few (see [1] to find some) but I don't know
how widely used they are.

RDF allows multiple types independently, as Mark noted, so the metadata
recorded can include information from different vocabularies.  The bnode
collects them together and says "they are about the same thing".

The trouble with the adapter route, and any involving mapings or
translations, is that they lead to M*N growth.  By mapping into a commonly
used ontology, we increase the sharability (the value of the data) and
reduce the maintenance of application-driven mappings.

In the specific example, of 

<Personal_Name>Leonardo,da Vinci,1452-1519</Personal_Name>

I changed to :artStoreId  because that is what this really is, as Eric
pointed out in the phone conference.  That is not his name - that is the
canonical way the art history world uses to create what is in effect a URN
by taking the name, canonicalising it and adding dates to differentiate
people with the same name.  If you want, add an equivalence relationship to
:artStorePersonalName but the machine doesn't care.

	Andy
	urn:uuid:29684948-2784-11b2-8000-fb3eb4ce406b

[[
Yes - it is (should be) a real, correctly constructed V1 UUID [2] as a URN
[3] excpt it uses a more modern seeding technique, not the 48-bit IEEE as
that is hard to get portably (Java) or without system code (Linux, Windows).

]].

[1] http://www.daml.org/ontologies/
[2] http://www.opengroup.org/onlinepubs/009629399/apdxa.htm
[3] http://uri.net/urn-nid-status.html

-------- Original Message --------
> From: Kevin Smathers <mailto:kevin.smathers@hp.com>
> Date: 10 October 2003 17:50
> 
> Seaborne, Andy wrote:
> 
> > Overall comments:
> > 
> > 1/ We need to decide what is the work/image relations here.  I see
> > three concepts: work, image, file.  Work and image from VRA core,
> > file from our own idea. 
> > 
> > 
> > 2/ <Description>Copy by Raphael</Description>
> > 
> > OK - so who is the creator? :-) There are two works the original and
> > the copy.  We an image, with several formats (different JPEG fiels
> > and a FlashPixfile) of the image. 
> > 
> > 
> > 
> As I read VRA, the creator is always the creator of the principal
> object, ie the object we are talking about.  If we are talking about the
> copy then the creator is Raphael.  If we are talking about a photograph
> of the copy of the original, then it would be the name of the
> photographer, but just because there is e.g. a digital photograph
> doesn't mean that we are talking about the photograph.  In standard
> usage photographs are surrogates for the objects that they represent --
> when pointing out things like stylistic elements of painting, we are
> still talking about the original object, even when looking at what is
> literally a photograph of a painting.  Creator only becomes the
> photographer when the element of discussion is e.g grain, or contrast,
> or lighting, or something that has to do with the photograph, and not
> with the original object that is depicted in the photograph.
> 
> > 
> > 
> > 
> > > <Creator>
> > > 	<Personal_Name>Leonardo,da Vinci,1452-1519</Personal_Name>
> > > 	<Corporate_Name>School of Leonardo</Corporate_Name> </Creator>
> > > 
> > > or
> > > 
> > > <Creator>Leonardo,da Vinci,1452-1519</Creator>
> > > 
> > > are both acceptable.
> > > 
> > > 
> > 
> > As we discussed in the phonce conference I think we need to process
> > the values to derive a "Person" class object.  Here it would be
> > (sketch example): 
> > 
> > [] :displayName "Leonardo,da Vinci" ;  # displayable form
> >    :name                               # Structured name
> >      [ :familyName "da Vinci" ;
> >        :givenName "Leonardo" ;
> >      ] ;
> >    :dateOfBirth "1452" ;               # or a structure   
> >    :dateOfDeath "1519" ; :memberOf                           # And
> >      need to allow [                                 # for attaching
> >       of date rdf:type :school;                # ranges?
> >       :name    "School of Leonardo"
> >      ] ;
> >    # Important: record the way that ArtStore refer to this person
> >    :artStoreId  "Leonardo,da Vinci,1452-1519" ;
> >    # Other corpuses ways of referring to this person    ....
> >    .
> > 
> > Giving people URNs makes them easier to reference.
> > 
> > The important thing is to record the ArtStore way of referring to this
> > person then adding a different corpuses way fo doing it, then we can
> > equate thsese to be the same person. 
> > 
> > Now the concept of "creator" is the relationship between the
> > work/image and the person - it's a property.  This captures the idea
> > of the 'role' being played.  The class of "Creator"s are those
> > "Person"s who are the object (in the range of) of a creator property.
> > Could also have a "created" proeprty - 
> > > Creator is a :Person with a :created property.
> > 
> > 
> 
> Creating an class for Person is fine, but combining multiple schemas
> into the same Person object I think is an error.  For example in this
> case you've changed the reference ':personalName' to ':artStoreId' which
> I think is erroneous since it destroys the original semantic meaning of
> the record -- the original semantics of the object properties get lost
> in trying to deconflict them with all of the other corpori that are
> integrated into the same record.  Furthermore, a simple approach of
> treating each corpus as a specialized subclass of Person would also be
> an error, in that it requires advance cooperation between all of the
> schema creators.  Rather than replace the original meaning, what you
> need is to apply an adaptor pattern to adjust the meaning to a new
> context; in other words, instead of extending Person with the contents
> of each new corpus, each new corpus can maintain its own Person class,
> each with its own meaning, but for the purposes of interaction between
> the corpori a new Person class can establish which records logically
> reference the same person.   (The logical basis for unifying the various
> Person records would establish the type of Person class being created.)
> 
> For example, a SoundExSimilarPerson class could run through names
> identifying names that are similar according to the specific SoundEx
> algorithm, and link together all records that match using that
> algorithm.   A separate e.g. GettyULANPerson class could link together
> records that contain identical Getty references for those records that
> include Getty references.

Received on Monday, 13 October 2003 08:29:35 UTC