tor 2006-01-05 klockan 17:34 +1100 skrev Sarah Pulis:

>  From your response, I have also realized that many of the issues or
> problems that I see (some listed in the previous email, others not)
> come from a difference between an abstract model versus a metamodel
> which will hopefully act as a data model that developers can use to
> store and manipulate DC metadata.

Well, in authoring the DCAM, we assumed it would be useful as such a
metamodel. From the introduction:

"This document is primarily aimed at the developers of software
applications that support Dublin Core metadata, [...]"

Although I can see your point - it's not a detailed system model of the
kind you use for software development. But I still hope the DCAM can be
used as a basis for such models.

> Take the example of the structure of a statement and the relationship
> between value and its representations.  Prior to your response, I
> didn't understand why a statement was structured as it was, nor that a
> value was the "actual" thing.  If I create a metamodel that is based
> on that structure (with those understandings), then it will be
> possible to have a statement with no value URI or value
> representation.  Let's say we use the metamodel to store DC metadata
> then export it as any Dublin Core recommended formats (such as XML,
> XHTML, RDF/XML).  I would say that these formats all require a
> tangible value, where a tangible value is either a value URI, value
> representation or rich representation.  If a statement doesn't have a
> tangible value, then I don't think the statement is going to be of any
> use in, for example, resource discovery.  What do you think?

"require" and "useful" are not the same thing. It's probably true that
not giving *any* indication of the value in a statement is probably not
very useful for resource discovery. But it's also not fair to say that a
"tangible value" is *required* - that would indicate a fairly complex
XML schema or RDF Schema/OWL ontology that implemented that requirement,
or alternatively some wording in the encoding documents. This is not the
case with current schemas or encoding documents.

Also, you forget the possibility of a related description. For example,
in RDF it is possible to have a statement with a blank node as object
(meaning no value URI is given). If also no rdf:value/rdfs:label is
given, this corresponds to your case of "no tangible value". However,
the blank node can be given any number of additional properties which
describe essentially any aspect of that value. This is the case with
most FOAF (friend-of-a-friend) metadata - no value URIs, no
rdf:value/rdfs:label, but only properties such as foaf:mbox etc.

So you have a case which corresponds to "no tangible value", but which
is very useful for resource discovery. We have deliberately made sure
that this option is left open in the DCAM for this very purpose.

> 
> It is become clear to me that in my design of a metamodel, some of the
> decisions made when designing the abstract model may need to be
> "diluted" or "polluted".  It seems there will have to be some
> trade-offs between the abstract model and the metamodel.

I would be very interested in hearing about your results on this point.
I think you might be right - producing a metamodel in your sense forces
you to specify some kinds of information that is better left unspecified
in a document with the kind of purpose that the DCAM has. That is
potentially one of the most challenging aspects of writing
interoperability specification: leaving things unspecified.

> 
> Your description of semantics did make things clearer.  You mentioned
> that "semantics" covers formal semantics (such as comments,
> definitions, sub-property relations, sub-class relations, ranges,
> domains etc.) as well as informal semantics.  In the resource model,
> the semantics that express sub-property relations, sub-class
> relations, even ranges and domains are modeled in the diagram through
> relationships between these class (such as property, sub-property,
> class, sub-class etc).  Semantics such as comments and definitions
> aren't explicitly modeled in the diagram.  Do you have any specific
> semantics (like the descriptive attributes outlined in the DCMT
> document) that you feel would fit in "the class that is semantics?"

I think that the "class of semantics" is probably unlimited in size. So
I think the question must be formulated as

  What semantics is useful/necessary for this specific *purpose*, in
this specific *context*, and for this specific *audience*?

(credit goes to Ambjörn Naeve for that formulation). If you don't know
your purpose, context and audience, you will fail in the specification
of what semantics you need.

That said, it would probably be fair to say that the attributes in the
"DCMI metadata terms" document are good candidates for most situations.
At some point, there was actually some discussion about producing a
"schema model" as well, based on the DCAM, that would give you a model
to use for describing metadata terms for use in DC metadata. That would
more or less be a formalization of those attributes, plus ranges,
domains, etc.

No such document has been proposed, however.

> 
> One other question came up while I was updating my description of the
> abstract model.  As I understand it, a class is the type of the
> resource, for example, a certain book on my bookshelf is a resource
> which belongs to the class of 'texts' where texts is one of the
> vocabulary terms defined in the DCMIType vocabulary encoding scheme.  
> 
> I am unsure about the statement "...where the resource is a value, the
> class is referred to as a vocabulary encoding scheme.  If I understand
> this correctly, the concept of 'text' can be both a class and a value.
> If it is a value, then it has a property of type and a vocabulary
> encoding scheme of DCMIType.  The value 'text' is also a resource and
> as such, it can have a class of its own.  In this case, the class will
> be the vocabulary encoding scheme DCMIType.  To make this possible, a
> vocabulary encoding scheme is a specialization of class.
> 
> If this is the case, then strictly speaking a vocabulary encoding
> scheme ISA class thus a sub-class can be related to (or refine) a
> vocabulary encoding scheme.  Is this intentional or just a by-product
> of the structure?

Your description is absolutely correct. The fact that vocabulary
encoding schemes are actually classes is an intentional feature of the
model. Not all approve of it, and the same (or at least similar)
structure has been modeled differently by, e.g., SKOS.

But still, this is the current situation. It can also be seen by the
fact that rdf:type is used to indicate the vocabulary encoding scheme of
a value in the RDF encoding (both the old and the new, in-progress one).

/Mikael


-- 
Plus ça change, plus c'est la même chose