I thought about writing a long reply to this, but decided I could sum
it all up as:
Good :-)
rob
On 26 Mar 2008, at 13:31, Karen Coyle wrote:
> Rob Styles wrote:
>> So in your example are you describing the need for page counts,
>> approximate page counts, section counts, numbering schemes and so
>> on? Or are we saying that having a page count value comprehensible
>> by anything short of Hal 9000 is too difficult?
>
> Yes. ;-) I think we need simple page counts, a pagination
> "statement" ("xvii, 356 pages"), the ability to count *whatever*
> (count:unit), and an escape for when it would be un-economical to
> both with detail. Since we have a deadline looming, I would begin by
> defining a pagination "statement," which is what RDA needs
> immediately. But I want to be sure that this plays well with the
> other elements that we could define -- are there things we need to
> do so that these have a good level of interoperability in the
> future? (See below - Mikail's suggestion)
>
>
>> Is it possible to define rigorous rules that could then be extended
>> and reconciled easily across a wide community?
>
> In essence, that's what RDA is supposed to be doing, but the sense I
> get is that RDA is still too "library" and "book"-oriented to gain
> wide acceptance. My feeling is that because of their focus on "how
> the strings will look" they cannot be sufficiently general. There's
> some hope that our project here will make it possible to see a
> general level, and perhaps rules could be extrapolated from RDA for
> those elements.
>
>> I can't help feeling that that will leave libraries still mostly
>> isolated in the wider world of information - using strings implies
>> not identifying entities in a way that they can be referenced. That
>> means that only the notional "manifestation record" would be
>> linkable giving almost no benefit over MARC. I think this approach
>> is why so many people seem to be saying "I don't get why RDF is
>> better than MARC".
>
> The properties will have URIs, and will be formally described. There
> will also be formally described roles. What I feel we can't easily
> do in "step 1" (which has an upcoming deadline, although I have
> forgotten the date but I feel the looming of it) is re-define the
> library data *values* beyond what they are in RDA today, although we
> may be able to take a few as examples and show what could be done.
> Oh, and we will also be registering the value vocabularies.
>
> Next, we'll need to establish RDA itself as an Application Profile.
>
> So what our discussion here started as was trying to figure out how
> the properties can be defined such that we can create an RDA AP that
> reflects the current stated data described in RDA, and yet be able
> to move beyond that into more rigorous data without sacrificing
> interoperability. I think that Mikhail answered that with "non-
> literal values" that take a literal value statement in an RDF:
>
> URI: rda:duration
> Label: Duration
> Definition: The duration of a resource
> Range rda:Duration
>
> 2. Blank node with rdf:value:
>
> R rda:duration _:x
> _:x rdf:value "29 min"
>
> Then my question was (and I don't think I got an answer): how can we
> define "Duration" such that a string like "29 min" and a more
> rigorous property definition:
>
> R rda:duration _:x
> _:x rda:hours "0"^^xsd:integer
> _:x rda:minutes "29"^^xsd:integer
>
> have the same semantics (thus retaining interoperability). I think
> the answer is that the Range can be broadly defined, and that more
> rigorous definitions must meet the "dumb down" rule (e.g. they can
> each be validly defined as "Duration" if their detail is ignored;
> thus the one above can also be expressed as "29 min").
>
> However, I think there may be some objections that this method makes
> use of blank nodes in each case where there is no URI.
>
> Diane and I are soon going to start working on sub-properties, as
> defined by RDA. We'll take a first pass at registering the
> properties and sub-properties. Meanwhile, at some point we'll need
> the above structure worked out so we can create the RDF/XML export
> from the registry. Of course, our first pass doesn't also have to be
> the last. We expect to learn along the way.
>
>>> I'd like to combine this with the question: "What is the real
>>> world that we are trying to describe with our metadata?" I think
>>> what will work will be a compromise between those two.
>> And here's the nub of the question - are we keeping a record of the
>> little bits of text printed on books, or trying to build a rich
>> network of information about who wrote, published, reviewed, cited,
>> was influenced by what over time?
>
> Yes. We have to do both. Or, at least we have to allow people to do
> one, either, or both.
>
> kc
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> [log in to unmask] http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
Rob Styles
Programme Manager, Data Services, Talis
tel: +44 (0)870 400 5000
fax: +44 (0)870 400 5001
direct: +44 (0)870 400 5004
mobile: +44 (0)7971 475 257
msn: [log in to unmask]
blog: http://www.dynamicorange.com/blog/
irc: irc.freenode.net/mmmmmrob,isnick
|