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