ons 2008-05-07 klockan 15:26 +0800 skrev Simon Cox:
> > Let's leave to one side for a moment the issue of whether this
> approach
> > makes the information represented by that XML fragment opaque to an
> > RDF/DCAM application: XML Literals are still good as value strings in
> a
> > DCAM description set.
> 
> That was my assessment. Encoding schemas are a useful extensibility
> point, which may be used in this way. 
> 

Yes, though it's certainly the most complex use of encoding schemes I've
seen, for good or bad.

> I guess that one of the principles of the DCAM and DCAP framework is an
> assumption that a record is modelled in its entirety using the RDF
> formalization, and that it should be serialized in a way that allows its
> content to be loaded and managed in a triple-store as a whole. 
> The benefits of this are that a single processing framework (RDF) can be
> used for the complete record. So superficially it could look like folly
> *not* to re-model the structure of a geospatial element as RDF. 

Well, it's really an engineering decision, I'd say. Look at dates and
names - some model dates as "2007-08-14", others use year, month, day
properties. Some model names using a fullName property, others have
separate properties for First, Last, Middle, Title, etc.

It all comes down do functional requirements, really. What kinds of
queries do you want to support over the data? What parts of the data do
you want generic RDF tools/harvesters/browsers/etc to be able to display
without knowledge about the particular XML format? 

> 
> However, there is a bit more to it, particularly in the case of spatial
> elements (which are the subject of the DCAP in question). In order to do
> sensible queries on spatial information, the functions can be quite
> elaborate - "point-in-polygon" is one of the simplest, and even it
> requires multi-field computations that would probably not be implemented
> in RDF. You would almost certainly need to bind in another processing
> library, so might as well use one that has already been built to support
> the existing (ISO) formalization. 

That tells me that there is a strong argument to group some data into
the XML format. Unless of course there are *other*, simpler but useful
things one can do with the data that does *not* require the full
processing power. "Is this west of that?" etc. This would need to be
analyzed carefully.

> 
> Remodelling in RDF might make sense for some elements in the GAP, though
> this would be most maintainable if the mapping from (for example) XML
> Schema was rule-driven rather than ad-hoc. 

Indeed. My experience is that rule-driven mappings from XML-based
formats require a high degree of regularity in the XML syntax, in
particular a more-or-less explicit underlying E-R model. In that case,
one can often do the mapping from underlying UML models or similar
instead of directly from the XML.

/Mikael

> 
> Simon
> 
> ______
> [log in to unmask]  CSIRO Exploration & Mining
> 26 Dick Perry Avenue, Kensington WA 6151 
> PO Box 1130, Bentley WA 6102  AUSTRALIA
> T: +61 (0)8 6436 8639  Cell: +61 (0) 403 302 672
> Polycom PVX: 130.116.146.28
> <http://www.csiro.au>
> 
> ABN: 41 687 119 230
> 
-- 
<[log in to unmask]>

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