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

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.



> 
> <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.

> In fact, they can even do both at the same time, as
> does <Subject> in the sample instance data
> 
> <Subject>Portraits
>   <Geographic>Italy</Geographic>
>   <Topic>Drawing</Topic>
> </Subject>

That could be tricky but in this case, it seems that the nesting is
artifical.  "Portraits" is the controlled term [1] just capitalized wrongly.
I couldn't find a refinement that include thenested terms.

[1]
http://webapps.getty.edu/vow/AATFullDisplay?find=portrait&logic=AND&note=&pa
ge=1&subjectid=300015637

Is the geography referring to the style of portrait or the location of the
work (i.e. confusion with the English meaning of "subject of portrait" being
the person painted).  We will need to look at the larger corpus. If there is
systematic usage here we can extract the conceptualization in converting to
usable RDF.  If its inconsistent, we may have to just drop it for now.

> 
> So the XSLT stylesheet had to use some tricks to get around this. Also
> the 
> schema will need to define properties in addition to classes where a
> mixed 
> mode nested element is converted to a class, e.g. a Creator element with
> nested elements is an instance of the Creator class, but if it contains
> text 
> as well this is represented as a creator property.
> 
> The second problem was deciding if the nested elements indicated
> superproperties, classes or context - see earlier email. I decided that
> 
> - Image, MediaFiles/MediaFile, Collection, Relation and Creator are
> classes. 


I don't understand why "Relation" is a class. I would have expected there to
be a property that links two things together ":isRelatedTo" (or even
rdfs:seeAlso).  Sometimes there are n-ary relationships and such a class is
needed but I can't see one here.

> 
> - Source is a superproperty used as a context e.g. there are two
> possible 
> instances of the Location element, one which is a nested element
> occurring 
> in MetaData, the other which is a text element occurring in Source. So I
> inferred these two uses of Location are different, so Source is being
> used 
> here as a context. As there are only two uses of Location, decided to
> replace <Source><Location> with a property called sourceLocation.
> 


> Outstanding issues:
> 
> 1. Does everybody agree with the choice of classes, as this strongly
> influences the model?

I would prefer to see more concepts - person, not creator for example as
that extends to other spaces.

Shall we sit down and do a deeper concept analysis of the ArtStore data now
we can take a few example records?

	Andy

Received on Friday, 10 October 2003 09:02:00 UTC