Kevin,
In part this is a philosophical issue, but I think it has practical
implications.
To begin with, I really hate the expression RWO (Real World Object)
because it makes it sound like we think we've got the actual person in
the Web, which we don't. We've got information about the person. But I
know that RWO is how that is said in the SemWeb environment, sigh.
I also understand your need to create a standard string that serves as
the identifier for the entity. There are undoubtedly many different
ways to do that. That string, however, is an identifier for
*something* identifiable, and something that could be included in
statements like:
BookA -- is authored by -- "x"
BookB -- has subject -- "y"
A string does not write books, and a string is not the subject of a
book. Some *thing* must fit into that formula. I assume that the
entity (here "x" or "y") would be represented by an authority heading
(today) or a URI (in the future). And that URI represents an entity.
The string is a display form (in the future) and is both a display
form and an identifier (today).
Where is the information about that thing in the MARC authority
record? I believe it is in the 1XX subfields, which *also* serve as a
display string *and* as an identifier.
Although library authority records use a string as an identifier, that
string necessarily represents some *thing*. It's been masked because
the information about the thing and the string have been overloaded:
one set of elements serves all three functions. The elements of the
string are not arbitrary, they attempt to represent real information
about a real entity.
It might help to contemplate the work done on FRSAD, which finds a way
to have it both ways: it has a thing and it has a string. The thing is
the entity that can act ("write") or be acted upon ("is subject"),
while the string is the human-readable identifier.
I honestly believe that MARC authorities has both the string and the
thing, and that reducing the authority data to a string is not
modeling what the MARC authority record means. I think you have to
represent both, even though MARC conflates them.
YMMV.
kc
Quoting "Ford, Kevin" <[log in to unmask]>:
> Dear Karen,
>
> You wrote:
>
> "Couldn't these properties be treated as properties describing a person
> rather than a collection:
> personName: Black Foot
> personTitle: Chief
> personDateofDeath: d. 1877
> ?"
>
> The short is: Yes, MADS/RDF *could* model information about the
> Person - the Real World Object that is the subject of the Authority.
> It doesn't, however. In the example you reference, the elementList
> orders the parts of the label (authoritativeLabel or variantLabel).
> [ The "Collection" you see in the example is RDF/XML shorthand
> syntax for an rdf:List and not really a whole/part relationship
> construct. ] When considering MARC as a source of inspiration for
> MADS, it so happens that the dates in any given label are often
> birth and/or death dates (the label would come from the MARC 1XX,
> but the dates in the label may merely be "associated with the name,"
> as detailed in the MARC documentation). So, it is tempting to
> bridge the logic gap and associate the dates directly with the
> Person, not the concept (with a controlled label).
>
> Now, in so far as MADS derives from MARC, MADS may eventually
> provide more room for information about the Person, especially as
> MARC data points are represented in MADS. If MADS properties were
> created for birth and death dates or gender, then I would expect that:
>
> 1) This information would be associated with the RWO (i.e. not the
> label) and
> 2) in so far as MARC was the source of the MADS description, the
> data would come from MARC 046 and MARC 375, respectively (i.e., not
> the 1XX)
>
> In terms of feedback/feature requests, would you (or anyone else,
> frankly) be interested in this information being represented sooner
> rather than later (I am confident that this information will
> eventually find its way into MADS/XML and MADS/RDF)?
>
> FYI: We are interested in keeping MADS/XML and MADS/RDF in sync as
> much as possible, which complicates the process a little, but this
> is also the forum for these types of requests and discussions.
>
> Warmly,
>
> Kevin
>
>
> ________________________________________
> From: Metadata Object Description Schema List
> [[log in to unmask]] On Behalf Of Karen Coyle [[log in to unmask]]
> Sent: Friday, April 01, 2011 17:02
> To: [log in to unmask]
> Subject: [MODS] MADS comments
>
> I have some comments that I probably should have made before, but the
> thoughts just came to me today due to something else that I was
> reading. I apologize also if this has already been covered and I
> missed it.
>
> 1. Names and parts
>
> MADS documentation says:
> "The madsrdf:Element class, and its associated sub-classes, provide a
> way to describe the parts of labels. For example, the name ?Black
> Foot, Chief, d. 1877? can be broken into 3 parts, or elements. ?Black
> Foot? is the madsrdf:NameElement; ?Chief? is the
> madsrdf:TermsOfAddressNameElement; and ?d. 1877? is the
> madsrdf:DateNameElement."
>
> Couldn't these properties be treated as properties describing a person
> rather than a collection:
> personName: Black Foot
> personTitle: Chief
> personDateofDeath: d. 1877
> ?
>
> To me this emphasizes the meaning of the properties rather than the
> display. Also, it may be just me but I think of collections as being
> like sets: a group of items that are equal for some characteristic;
> the collection of "things in my garage", where they can be quite
> varied, but the main interest is that for this purpose they are things
> in my garage. I'm a bit uncomfortable with the 'part/whole' use here,
> although I don't know that OWL excludes that possibility.
>
> 2. VIAF and MADS are playing around in the same sandbox. VIAF has
> "hasEstablishedForm" and MADS has "authority". They probably aren't
> identical in meaning, but this seems an ideal moment to think about
> authorities in a larger sense. Have the two organizations talked about
> such a collaboration?
>
> kc
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|