I have been looking at how to handle a faunal assemblage. Our 'normal'
assemblages are generally a pot type with a count (number of counts).
This works on the backend by chaining the pot (attribute) direct to
the Item and then chaining numbers onto the attribute.
i.e.: Cxt_9087(item) -> RomanAmphora(attribute of atttype 'pot') ->
47 (number of numbertype 'total').
However, we may need to think about this is a different way if we are
looking at combinations of things. For instance, I have a table that
records the counts of Male Adult Cow Humerus' and then Female Juvenile
Cow Phalanges, etc. Effectively a chaining of 4 different attributes
with one count.
But we need to bear in mind these counts also stand true for the
individual attribute itself. For example if I have a count of 5 male
cow tibia, this means that I effectively have 5 cow bones or 5 male
bones or 5 tibia or 5 male tibia or 5 cow tibia - or any other
combination. We would want to be able to at least give the option of
displaying this aggregated data, which we can;t currently do with the
single attribute (as we would need to make individual attributes for
each - male_cow_tibia_adult) which is not very flexible.
Therefore I propose that we make an adjustment to the sf_assemblage or
alternatively make an sf_multi_assemblage or something, that does the
linking and chaining in a different way. We link the count direct to
the Item, and then link the attributes off that.
So we would have one or more 'faunal_count' number(s) attached to the
item - which then have attributes chained to them. This allows us to
aggregate ARK-wide on individual attributes if we want to - but we
can also display this info in the sf_assemblage - by combining the
attributes using PHP. It may need a bit of adjustment as to how we
deal with chains within the search functionality (i.e. we would want
to be able to search for cow and get back the item not jsut the number
its attached to).
I have attached a diagram that might make it a bit easier to
understand. The top one is the current situation and then the second
show the proposed new way of doing it, with a query as well.
Anyway, let me know thoughts - I think I will give it a go on a
prototype and then we can discuss if this is something we want
integrated into the core.
Stu