 |
 |
(Comments embedded below). On Fri, 10 Oct 2003, Mikael Nilsson wrote: > The first is a general insight that Roland and I had in a discussion in > Seattle. The problem is this: if you start using RDF resources as values > of the DC properties, you are introducing new types of items into your > data. These types are of kinds like "entity", "date", "title" (or maybe > "natural language string"). LOM has such types, and it's actually very > helpful in the RDF modeling. > > We discussed the well-known fact that when building a database, you > start with defining the types (=tables), and then go on to defining the > properties of these types of objects. > > But in DC, these types do not exist. The only kind of types that are in > the DCMI type vocabulary are the different types the resource itself can > have, not the types of the typical *values* of the properties. The > conclusion here could be that DC lacks a project defining some of these > types. Yes, Pete suggested something similar... defining a set of classes like dcclass:Subject dcclass:Date etc., to use to label the value resources. What I'm not 100% clear about is whether these classes form part of the abstract model or whether they are just a feature of the way that the abstract model is instantiated in RDF. My feeling is that they should be a part of the abstract model - and further, that these classes are implied by, but not made explicit by, the current XML and XHTML syntaxes. > b) > <res1> <dc:date> _:xxx > _:xxx <rdf:type> <dcterms:W3CDTF> > _:xxx <rdf:value> "1999-03-13" > > Given that we want to start using resources always for values, the > unqualified example would now look like: > > c) > <res1> <dc:date> _:xxx > _:xxx <rdf:value> "1999-03-13" > > I now see at least two ways of adding an element encoding to this > construct. The first is exactly b), that is, adding a new <rdf;type>. > Note how the simple and qualified versions are 100% compatible (great!). > > On the other hand, we have discussed if RDF datatypes are going to be > introduced in the qualified DC encoding. So there's another possiblity: > > d) > <res1> <dc:date> _:xxx > _:xxx <rdf:value> "1999-03-13"^^<dcterms:W3CDTF> > > Note how this is *also* 100% compatible with the unqualified version. Of > course, we should probable just map W3CDTF to to the XML Schema "date" > datatype (or datetime? I'm no expert, help!). So we would have > > e) > <res1> <dc:date> _:xxx > _:xxx <rdf:value> "1999-03-13"^^<xsd:date> > > Looks good, eh? Is e) how we want to represent element encodings? For > all properties or only for some? Or is using the RDF datatype construct > just something outside the scope of DC, and we should stay with b)? > > My opinions: > > e) looks really good. I'd love to see that. However, I feel the lack of > a typing of the resource. I'd like it to be a <dc:Date> or something > like that, as per the previous comment... > > b) does *not* look good to me. The resource is *not* a W3CDTF object. > The resource is a "date", nothing else. The *string literal* is in > W3CDTF format, not the resource. > > However, for <dc:subject> encodings, look at: > > f) > <res1> <dc:subject> _:yyy > _:yyy <rdf:type> <dcterms:MeSH> > _:yyy <rdf:value> "A01.34" > _:yyy <rdfs:label> "Abdomen" > > In this case, the resource (_:yyy) might actually *be* a Medical Subject > Heading, so the current encoding (that is, the b) version) is maybe the > right one. So I'm not sure which way is right. > > In any case, it would be really great if we could solve some of these > issues.... I want to use the constructs in the LOM RDF binding :-) > > Any opinions? I've been thinking about these issues also. I was wondering if there is a fundamental difference in the nature of what we currently refer to as 'syntax encoding schemes' and 'vocabulary encoding schemes'. It could be argued that a syntax encoding scheme (like W3CDTF) says something about the way the 'value string' is formatted - but it doesn't tell you anything about the class of the value resource (_:xxx in example d) above). On the other hand, vocabulary encoding schemes do tell you something about the class of the value resource - 'this value resource is a MeSH subject' - so modelling this as in f) above looks right. We would define dcterms:MeSH to be a subclass of dcclass:Subject. However, I then began thinking about what value URI we would give to the value resource in the date example, example d). My guess is that we would, if we were allowed, give the resource a URI something like http://w3.org/w3cdft/2003/03/28/ i.e. we would give it a W3CDFT-specific URI. I therefore wonder if the current modelling is correct, i.e. that the value resource is infact a 'W3CDFT Date' rather than just being any old 'Date'? If so, then I think the current model used in b) above is sufficient and correct. ?? Andy -- Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933 Resource Discovery Network http://www.rdn.ac.uk/