I find the proposal that Carl advances appealing in several respects.
- It protects the use DC as an element set for simple description
- It promotes a standard convention for arbitrary subgraph expansion -
essential for many applications, and the sooner we promote a common means of
encoding such extentions, the less encoding divergence will occur.
However,
- It is not obvious to me that it is necessary to include a null INTNODE in
cases that DO NOT have subgraphs; is it not sufficient to simply invoke the
rule:
Properties will terminate in either an "appropriate literal" or in
another node (INTNODE); in the latter case, the "appropriate literal" for
the property is identified by the rdf:value arc.
Thus, the following structures should both allowable (I think).
R1 ---------------> "apprt. literal"
dc:property
R1 ---------------> INTNODE ------------> "apprt. literal"
dc:property | rdf:value
|
|
-----------------> arbitrary subgraph
I would like to hear more from implementors on this question
As for Carls objections to his own proposal:
1. It is tightly bound to RDF...[which] ...given the
immature state of RDF tools and practices, this may be a bad idea.
stu >>> I think this is a significant issue, though in fact there many
more RDF applications coming online all the time, including a variety of
tools by DC groups, so I'm less worried about this as time goes on, and we
are NOT saying that RDF is the only way to do DC.
stu >>> Besides, we know that the use of XML DTDs leads to far worse
factionalization - extensibility and modularity are severely crippled in
this model.
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).
stu >>> I believe that Tom's grammar paper essentially proposes a data
model for DC metadata, but does not, nor should it, constrain an encoding of
that data model. I don't see a conflict here, as long as a sensibly written
parser extracts a "metadata sentence" that is consistent with the grammar.
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.
stu >>> I agree that this is a significant danger. One way to avert this
danger is to enforce the "appropriate literal" convention *AND* to promote
only the use of formally defined schemas as appropriate subgraphs. One pof
the roles of the DCMI Registry should be a repository of such schemas or
pointers to schemas maintained by others
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
stu >>> I agree with these alternatives... my feeling is we will do each of
these things:
a. ... we can ignore them... there may be many that are local and not
of interest inasmuch as they do not support interoperability (but people
will still want to use them). meanwhile, we still have appropriate literals
to fall back on.
b. put them in the registry at the request of metadata managers that
want to disclose them as potentially usefiul to others
c. Evaluate them... I can imagine that a handful of such structured
values would attract broad attention as candidates for standard blocks in
our DCMI lego set... an Admin Core, and Agent Core, etc.
stu
|