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

Hi Andy

RE: Works, Images and Files

This is a good point. One extra thing we could do is cross-check our model
against the FRBR (Functional Requirements for Bibliographic Records) spec
http://www.ifla.org/VII/s13/frbr/frbr.pdf

They have a group 1 entity which is divided into four classes (see page 21
of the spec): work, expression, manifestation and item. There is a
corrspondance here:

VRA:work corresponds to FRBR:work
VRA:image corresponds to FRBR:manifestation
VRA:file corresponds to FRBR:item

So perhaps we would be best using the FRBR terminology?

 
RE: The concept of creator

This is a good point, and again FRBR is relevant here. They introduce group
2 entities, which can either be people or corporate bodies, and are capable
of having "created by", "realized by", "produced by" and "owned by"
relationships with group 1 entities. So perhaps we need to make a superclass
(any suggestions for name?) for Person and CorporateBody, which is the range
of the "createdBy" property. 

Artstor seems to expect these type of relations, as in the XML version the
<Creator> element can have subelements <Personal_Name> and <Corporate_Name>.



RE: Subject, Geographic, Topic

The way I interpreted this information was that Portraits, Italy and Drawing
are keywords associated with this work. The tags around Italy and Drawing
are subproperties, which indicate they are keywords from a geographic
controlled vocabulary and a topic controlled vocabulary respectively. 

However your point that the relationship between the keywords and the work
are ill-defined is a fair one, but often the case with keywords - perhaps
MacKenzie can comment here?

The other important bit of FRBR that seems to be missing from our conceptual
model are group 3 entities: concept, object, event and place. In FRBR, works
can have a "has subject" relationship to group 1, group 2 or group 3
entities. 
 

RE: Why is relation a class?

This was based on my reading of the XML schema, rather than any modelling
decision. In the schema says that a relation can consist of
- a text item
- an identity element
- a type element
and it seems like it multiple relations are possible e.g.

<Relation>
	<Identity>Head of a Woman, by Leonardo da Vinci</Identity>
	<Type>Copy</Type>
</Relation>
<Relation>
	<Identity>Photographic Study, by Vincent Steels</Identity>
	<Type>Photograph</Type>
</Relation>

although admittedly I am guessing here without seeing more examples of their
data. So I thought we needed a class because type and identity need to be
associated together.

However, as you note, from modelling perspective, relation does not seem a
good candidate for a class. I'm not sure how to resolve this. The FRBR spec
does discuss relationships between group 1 entities, see page 53, perhaps
this is relevant?

kind regards,

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Friday, 10 October 2003 10:40:40 UTC