Stu and others,
Tom Baker and I had a long discussion about this structured value issue
this morning. Here's what came out of that discussion that, as always,
is filtered through my own prejudices and distortions. Tom will
hopefully chip in with his own interpretation.
A few facts, as I see them and I believe Tom agrees in principle:
- The primary goal of the DC elements should be metadata for simple
resource discovery. I go on in depth about this in [1], 'nuff said.
- Essential to this goal is the principle of dumbining down and the
"apporpriate literal" as defined by Tom in [2]. Any solution to the
so-called structure value issue must take this into account.
- People will and have already used DC element as general buckets for
whatever information they desire that appears to be related to the
concept space of the element definition. Agents are an outstanding
example of this (e.g.., organization, affiliation, email address,
birth/death date, etc.) but as pointed out in [1], this situation is and
can be replicated for each element.
We need to have a way of accomodating our goal - simple resource
discovery - and the actual usage practices.
Various people, including Tom, see the use of RDF:value as a means of
doing this. As I state in [1]:
The RDF model [3] includes a so-called RDF:Value property for denoting
the "principal value" of an entity with multiple properties. This can be
used to designate a "default value" for a complex, nested value
structure -- in effect offering a way to embed simple pidgin statements
for resource discovery within descriptive constructs of arbitrary
complexity.
In practice this would require the use of an "intermediate node" in the
RDF expression. Such as:
R1 ---------------> INTNODE ------------> "apprt. literal"
dc:property | rdf:value
|
|
-----------------> arbitrary subgraph
The arc coming out of the bottom of INTNODE above could be an arbritrary
large collection of arcs representing properties in other namespaces
each or which points to an arbitrarily large sub-graph.
The meaning of such is that the "simple resource discovery value" of the
dc:property is that linked by the rdf:value arc - other stuff (the other
arcs and the arbitrary sub-graphs linked by them) is a value space
outside the scope of Dublin Core.
If we are in favor of this proposal, and I think we need counter
proposals, we should then immediately modify our suggestion for encoding
DC in RDF/XML to always include the intermediate node - as in the
degenerate case:
R1 ---------------> INTNODE ------------> "apprt. literal"
dc:property rdf:value
without the other properties. I think that having two encodings, one
where there are not other values present and one where there are other
values present is a bad idea. If we are to advocate/allow the
association with dc properties arbitrarily large value spaces then we
should incorporate it at the base level.
This all said, let me know present some problems with this suggestion,
as a way of stimulating discussion:
1. It is tightly bound to RDF. As I point out in [1], given the
immature state of RDF tools and practices, this may be a bad idea. I've
strongly disagreed with Ren's objections about the wrapping of DC XML in
RDF tags - thats mostly a red herring since XML is agnostic to how you
containerize elements. However, in this case we are linking semantic
interpretation (e.g., the indication of a default value) to a rather
esoteric part of the RDF M+S, making me uncomfortable.
2. It violates Tom Bakers grammatical principles as defined in [2]. Tom
carefully defines "DC statements" with a structure where the value is an
approprite literal. In the proposal above we are contradicting that
with an "RDF sentence" with predicate (property) that is a dc element
(e.g., creator) and an Object (value) that is a sub-graph containing any
complex value set. We need to decide exactly what is the grammar of DC
and need to recognize that, if we rely on RDF, DC will exist in the
model of RDF and that model will define the way machines interpret DC
statements (in the same general manner as it interprets properties from
other namespaces).
3. It encourages communities to (mis)use DC elements as dumping grounds
for "anything having to do with the original meaning of the element. I
think that we should encourage good practice which in my terms means
using DC for what it was intended (simple resource discovery,
appropriate literals) and encouraging communities to come up with richer
vocabularies to express their own more complex needs.
4. I don't know what the role of the usage committee is in dealilng with
these arbitrary value subgraphs. Tom and I spoke at length about this
and I agree and support with the role of the usage committee in
evaluating the use of the "appropriate literal". However, with the more
complex value space, we are left with the following not entirely
satisfactory alternatives:
a. Ignore them and say they are none of our business - "we are only in
the simple resource discovery business"
b. Document there use - for example, keep some database of the various
schema used to define them.
c. Evaluate them - I struggle then to come up with deterministic
principles by which we could evaluate them. Note that we do have
deterministic principles by which to evaluate qualifers as defined in
[4]. John Kunze in exhasperation in the past raised the proof by
contradiction prinicple - e.g., tell me what is **NOT** a legal dc
qualifier. That applies here, if we come up with principles than we
need to apply the test and unequivocally determine what is **NOT** a
good "complex value".
Carl
[1] http://www.dlib.org/dlib/january01/lagoze/01lagoze.html
[2] http://www.dlib.org/dlib/october00/baker/10baker.html
[3] http://www.w3.org/TR/PR-rdf-syntax/
[4] http://purl.org/DC/documents/rec/dcmes-qualifiers-20000711.htm
> -----Original Message-----
> From: Weibel,Stu [mailto:[log in to unmask]]
> Sent: Tuesday, February 20, 2001 10:44 AM
> To: [log in to unmask]
> Subject: vCard as a structured value strawman
>
>
> As regards vCard... I suspect the vCard fragments being
> bandied about should
> not go in the Guide document immediately, but could be used
> as a strawman to
> get this problem solved.
>
> Question for the Group:
>
> What would we need in the way of demonstrated implementation
> experience to
> actually decide we have a workable solution that scales to our other
> problems of structured values?
>
> If there are implementors who are using it and can
> demonstrate that it meets
> the architectural constraints of the DC Architecture, solves
> real problems,
> and is manageable, then one approach might be to develop a
> DCMI Application
> Note that identifies the conventions in use and calls for others to
> implement in an interoperable manner.
>
> stu
>
|
