Tom, Mikael
I have made a first read through the two documents you referred to at
our meeting, ie, the DCMI abstract model and the RDF representation. I
have some comments, I hope they are helpful.
- This is more of a question than a comment. Is there any particular
reason why the vocabulary encoding scheme is not used simply as a class,
and use rdf:type instead of dcam:memberOf? I am sure you discussed that,
and you have your reasons, but I am just curious...
- In section 5 of the RDF mapping, section for 'Value Classes', you say:
[[[
The property dcterms:type is a sub-property of rdf:type. However, it is
recommended that applications implementing this specification primarily
use and understand rdf:type, as it cannot be assumed that all RDF
processors will understand the sub-property relationship, while most RDF
processors do come with built-in knowledge of rdf:type.
]]]
The problem I have with this is as follows. If the specification of
dcterms:type is indeed formally defined as a subproperty, then I'm
afraid the consequence is that all ontologies referring to it will be
kicked out of OWL DL. (It is not allowed to make any statement on a
'core' RDF term like rdf:type). The sentence above is, in any case, a
bit 'fuzzy' for my taste. Why don't you stipulate that the RDF mapping
of the DCMI abstract model maps 'dcterms:type' to 'rdf:type', and that
is it? I understand that dcterms:type might be useful to have in other,
non-RDF encodings, but it should be o.k. to restrict it for an RDF
mapping (and avoid problems on the OWL level)
- There is still another problem with the OWL DL, in my view. *If* you
want to define, say, dcterms:creator in OWL, you will have to specify
whether this is a datatype property or an object property. In DL, they
cannot be both at the same time (and you seem to stipulate that). You
may have deliberately chosen to do so, but I just want to highlight this.
Note, by the way (remember my question on OWL1.1 at the end of the
meeting?) that in OWL1.1 you might get away with this, due to punning
that they plan to introduce. The problem is that punning creates lots of
other problems in OWL1.1, it may become one of the features "at risk".
Another way out would be to explicitly define two properties for each of
these cases, one for datatype property and the other for object
property. This is ugly, I know...
Of course, you may decide to ignore the problem and *not* aim for OWL
DL. In which case both these two comments can be ignored (although I
still find the paragraph referring to rdf:type above a bit 'fuzzy').
- In the very last example of the RDF mapping document I would have
expected the 'ValueId' to be mapped on an rdf:ID and 'ResourceId' simply
to an rdf:about="#john".
That, of course, means the creation of a full URI, in fact, ie, the
resource identified with 'john' will be visible outside the RDF/XML
file. If this is not what you want, then you could also use nodeId to
create a blank node with those id-s. I am not sure which approach is
more appropriate for you (I would expect the former).
I hope these are helpful!
Thanks
Ivan
|