- From: Makx Dekkers <mail@makxdekkers.com>
- Date: Thu, 11 Sep 2014 09:45:40 +0200
- To: "'Andrea Perego'" <andrea.perego@jrc.ec.europa.eu>, "'Frans Knibbe | Geodan'" <frans.knibbe@geodan.nl>
- Cc: "'Simon Cox'" <Simon.Cox@csiro.au>, "'Oscar Corcho'" <ocorcho@fi.upm.es>, "'LocAdd W3C CG Public Mailing list'" <public-locadd@w3.org>
> > Probably (but Makx can correct me if I'm wrong) the point was that, in > that point in time, DC terms were used just with literals, and not > with class instances. In our case, the question is whether processing > would better be done at property level (:resolution vs > :spatialResolution) or rather at class level (:QuantityValue). > Yes, in fact, if you get a string value in dc:coverage, there is no way to know whether it indicates time or place. If the string is encoded as DCMI Point or DCMI Period, you can but the usage of those encodings is not mandatory. In a linked data approach it is slightly better because you can figure it out by resolving the Object URI and seeing what type/class the identified resource is, but that requires extra work. The fundamental problem as I remember was that people thought it was not really a good idea to have ranges that contained "or" joining different things: classes CatOrDog, StarSystemOrMolecule etc. might be of some use to someone, but it was thought that it would be better on the general level to define the classes like Cat, Dog, StarSystem, Molecule separately and then create joins when you really need them. Makx.
Received on Thursday, 11 September 2014 07:46:14 UTC