On ons, 2007-02-07 at 17:31 +1300, Douglas Campbell wrote:
> 6. Section 5 "DCMI Abstract Model semantics" - I'm assuming this
> section is to provide guidance on the model's relationship to RDF?
> Key things I'd want to know are:
> a). What does-not/will-not map to RDF (the table only shows what
> _does_ map)
The aim is to update the RDF encoding to make sure it maps *everything*
in the DCAM description model.
What the table shows is not really the mapping of descriptions, but
rather mapping of the *concepts*. Maybe that can be made more clear...
> b). Can this model be used directly in the RDF world, ie. if I use
> this will it break in an RDF environment?
Hopefully not (that is one of the design goals after all!). When used in
RDF, it can be seen as kind of "modeling style" or "design principle"
for metadata, an abstraction living on top of RDF. This will be made
clearer in the upcoming RDF encoding, but is hopefully clear already
from the existing draft:
http://dublincore.org/documents/dc-rdf/
>
> Where I'm coming from: I don't confess to know a lot about the RDF
> world, but it seems to me that a generic RDF application will have to
> at least have a base set of properties it understands - it is possible
> to discover what any unknown resource or property is by following
> defined RDFS or OWL relationships, but ultimately your application
> ends up at a text description that will probably need a human to
> interpret (either through providing realtime feedback to the text
> descriptions or by programming support into the application's code for
> future encounters). The DCMI Terms set seems to me to be a good base
> that all applications could be coded to understand, then all
> properties that sub-property off them at some level could be
> understood. So I'm just wondering if our abstract model is
> sufficiently robust to play that role?
It's designed to, and the work on property domains and ranges enhance
that aspect considerably, in my opinion. Any problems in this aspect are
of critical importance, so if you find any, please report...
/Mikael
--
<[log in to unmask]>
Plus ça change, plus c'est la même chose
|