[auscope-geosciml] draft summary: what does xlink:href actually refer to

Clemens Portele portele at interactive-instruments.de
Wed Aug 10 02:34:22 EDT 2011


All,

Ollie has forwarded me the exchange so let me add a few thoughts to Steve's nice summary:

- On the conceptual level the target of the samplingFrame association role is an instance of a SamplingFeature. So, from that conceptual model point of view I am perfectly fine with the model as it was/is. The problem is that the same model serves as an implementation model, too, to derive the GeoSciML XML grammar using the standard encoding rules (with some extensions). And since GeoSciML is called a markup language the XML is probably key. If this is not what is intended, maybe a separation into a conceptual model and an XML implementation model could help to clarify the requirements on implementations.

- There are also issues how to integrate all this with the rest of the architecture. Take a look at WFS. Neither WFS, Filter or GML say anything about content negotiation. Sure, one can argue that this is in a way implied by HTTP, but without clearly clarifying the requirements on software packages this will be difficult in practice. Which existing WFS servers/clients use content negotiation when dereferencing Xlinks? So, the requirements have to be made explicit and this is what the discussion attempted in Edinburgh. Quite clearly, this was more on an implementation level than the conceptual level, but expressed in the conceptual model for the reasons mentioned above.

- On the WFS level it is also not always clear what all this means in WFS queries. I.e., further clarification on requirements is required. For example, if a WFS would support "remote resolve" queries could put predicates on the properties of the sampling feature and the WFS must honour them. I do not see how this could be done, if the only available representation is a label.

- I am a bit concerned if every community would develop its own rules how this works as essentially this would mean that, for example, WFS software packages would have to become community specific. So, whatever GeoSciML decides to do, it should be brought into the OGC process (and GeoSciML should at least consider to adopt what the result of the process is).

- The GML encoding rules basically require at the moment that what the xlink of an association role by default references is a well-known XML element (see gml:targetElement,; usually the GML representation of the target classifier). I understand that this is more restricted than what HTTP offers, but this is what we have in the current rules. 

Clemens


Am 09.08.2011 um 20:44 schrieb Stephen Richard:

> (renamed thread from “Re: [auscope-geosciml] RE :  RE :  RE :  RE :  GeoSciML ready to do for               FullMoon [SEC=UNCLASSIFIED]” )
> Draft proposal for summarizing this very interesting thread…
>  
>  
> Premises:
> ·        In the conceptual model, the target of the samplingFrame association is a SamplingFeature;
> ·        A term is a symbol for some concept. Functionally, every term that is used in communication operates as an identifier for some referent.
>  
> We’re dealing with a computer system, so the actual sampling feature can’t be delivered. In an implementation that we are using, there must be some representation of the SamplingFeature that is the target of the association.
>  
> We are using an XML implementation of a conceptual model—conceptual elements in the model and their instances are represented by text strings using XML syntax.
>  
> We are proposing to serialize a reference to a SamplingFeature using xlink:href instead of including an XML representation of the SamplingFeature inline. Operationally, because we are using XML, this reference is a text string.  We can call it a ‘label’ or ‘term’ or ‘URI’, but in the end there has to be some way to know what it refers to or it’s not useful.
>  
> We all seem to be in agreement that the reference text string is an http URI that can be dereferenced using the web to obtain a representation of the Sampling Feature to provide the meaning of the reference.  The question is does this representation have to use the same XML representation as the inline representation dictated by the SWE schema.
>  
> In order to enable interoperability, there has to be some agreement on what kind of representation the dereferencing will get. The nature of the representation should be determined by http headers/content negotiation. This kind of agreement is a service profile level agreement, not a schema, model or service (http, WFS) level agreement. We have to decide what will happen in a ‘CGI GeoSciMLv3 standard mapped feature WFS service’.
>  
> So far it looks like application/gml+xml should give an xml snippet for a SamplingFeature; perhaps application/skos+xml would give a SKOS representation, and text/html would give a web page explaining what it is.  Xlink:roles can be used here, but the URIs should probably identify the same mime types…
>  
> Stephen M. Richard
> Arizona Geological Survey
> 416 W. Congress St., #100
> Tucson, Arizona, 85701   USA
> phone: 520 209-4127
> AZGS Main: (520) 770-3500.  FAX: (520) 770-3505
> email: steve.richard at azgs.az.gov
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Thursday, August 04, 2011 7:34 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> TO clarify –
>  
> -        The target of the samplingFrame association is a SamplingFeature; it is not a ‘term denoting a sampling feature’; a ‘term’ cannot be equated with a ‘SamplingFeature’
> -        The requirement is to be able to serialize the reference to a SamplingFeature as a label, rather than inline: we can do this already, using xlink:href
> -        Sometimes there is no GML serialization of the target SamplingFeature available; in this case we want to be able to refer to it anyway, using a term to refer to it
> -        A URI is ultimately just a text string (albeit one with an implied contract of resolvability), so can easily serve the purpose of being a ‘term’
> -        Making the model say that ‘either a term or a Sampling feature is the target of this association’ is muddleheaded and unnecessary, and furthermore wrong and therefore misleading. Don’t do it.
> Simon
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Wednesday, 3 August 2011 7:47 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: [ExternalEmail] Re: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> Any rule that replaces one class with two but which does not change the semantics is an unnecessary complication.
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
> Sent: Wednesday, 3 August 2011 9:44 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> I guess I’m having difficulty seeing what type of rules constitute “model pollution” and what rules don’t.
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Wednesday, 3 August 2011 9:40 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> If you want additional rules that is fine but they should not pollute the model.
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
> Sent: Wednesday, 3 August 2011 9:32 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> I guess you know this already, but I’m still with Eric on this one, naivety and all.  The GeoSciML model moved beyond being just a conceptual model long ago, and as Eric says, restricting some of the loose options of generic web architecture by defining specific geological community expectations for data content in our model is a good thing for interoperability.  
>  
> The generic web protocols might allow a wide range of data content to be delivered, but as a scientific community concerned with ease of data exchange, surely we don’t want data providers providing anything they feel like in an xlink:href.  For instance, we have included throughout the model that many attribute properties are to be delivered by xlink:href to a controlled vocabulary (ie, we have restricted, as much as we can, what we expect the xlink:href to resolve to).  That’s not just a conceptual model - that’s stating explicitly how we want the delivery of the byReference element implemented.  The MappedFeature/samplingFrame UML model is also explicitly stating how we want the information delivered.
>  
> Yours in naivety,
> Ollie
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Wednesday, 3 August 2011 8:13 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> “I was just naively expecting that reference from within a giving serialisation would be consistent. ”
>  
> That is not required by the web architecture.
> It could be an additional requirement of GeoSciML, but in general I think we should avoid deviating from standard web assumptions more than strictly necessary.
>  
> Simon
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
> Sent: Wednesday, 3 August 2011 7:49 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: [auscope-geosciml] RE : RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> >Media-types and the model are separate concerns.
>  
> yes, I know that.  I was just naively expecting that reference from within a giving serialisation would be consistent.  If within GML/XML, you refer to stuff serialized in the same representation.  What I was against is mixed representations unless specifically stated.  But I see your point.  Web is loosely coupled.  But this it is also fuzzy and this is why complex application are limited (hence, the reason to have RDF as a standard to structure content - ditto for GeoSciML)
>  
> ok . let's me rephrase this just to check if I got this correctly. (Sorry, I'm the slow one).
>  
> a) When a xlink:href is dereferenced, it is not garanteed that you'll get GeoSciML even if this is what the model states and it is what you ask.
> b) you must write a GIS application that ingest web reference (even if it comes from a WFS) is such a way that it should gracefully handle whatever it does not understand.  Therefore an operation is never garanteed to complete even if the provider claims "compliance" to GeoSciML.
> c) you can't know in advance,
> d) UML model documents only GML instance "exactly", might be use to bind OWL or RDF or JSON (because they have a possible mapping to the UML model), but is useless for any other media-type (you can't process them based on knowledge of UML).
>  
>  
> I remember some guy saying that having multiple options was the enemy of interoperability.  ;o)
>  
> Eric
>  
>  
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon.Cox at csiro.au
> Date: mar. 2011-08-02 17:19
> À: auscope-geosciml at lists.arcs.org.au
> Objet : Re: [auscope-geosciml] RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> Eric –
>  
> Media-types and the model are separate concerns.
>  
> Different clients will prefer the same content (model) in different representations (media-types).
> I agree that most GeoSciML/XML clients would prefer that dereferenced URIs would also be in GeoSciML/XML.
> Thus I would expect clients processing GeoSciML/XML would usually set the HTTP headers to Accept=application/gml+xml.
> This is a client application expressing a preference, and is independent of any information contained in the document.
> But I do not agree that this means that references in GeoSciML/XML documents may only be to sources that can supply this, and consequently the client must be configured not to break if the server sends something different back, as allowed for by the HTTP protocol.
>  
> The web, including the XML part of the web, is not a closed world, and you will have to accept some dangles and media-type boundaries.
>  
> Simon
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
> Sent: Wednesday, 3 August 2011 7:11 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: [auscope-geosciml] RE : RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> >The web architecture is deliberately forgiving about hypertext links.
>  
> Yes, but the possible use cases are reduced accordingly.
>  
> >Ultimately it is up to the client application to know what media-types it can handle and to ask for them.
> And the client application will get this information from the model..  otherwise, why bother creating a model if anything goes ?
> 
> >This is all part of the HTTP protocol, and this is the place to solve the problem, not by messing around with the conceptual model.
> ok - you lost me. How an application is suppose to know how to process the content if it can even be garantee to get what it expects ?.  This loose architecture just brings us back to a collection of HTML pages linked together.  If you allow a vocab to be return instead of a SamplingFeature, what prevents this to happen to all other xlink:href (byReference) in the model ?
> 
> I'm just confused.
> 
> Eric
> 
>  
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon.Cox at csiro.au
> Date: mar. 2011-08-02 16:45
> À: auscope-geosciml at lists.arcs.org.au
> Objet : Re: [auscope-geosciml] RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> The web architecture is deliberately forgiving about hypertext links.
> I agree that content negotiation has an important role here, but that should be done in the HTTP layer, not in the data.
> Ultimately it is up to the client application to know what media-types it can handle and to ask for them.
> Then the server can say ‘OK’ or maybe just ‘Sorry, this is all I’ve got’.
> This is all part of the HTTP protocol, and this is the place to solve the problem, not by messing around with the conceptual model.
>  
> BTW – remember this? – https://www.seegrid.csiro.au/wiki/CGIModel/EarthNaturalSurface
> This is not a new problem.
> I’ll work up GML and RDF versions of it later.
>  
> Simon
>  
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
> Sent: Friday, 29 July 2011 7:36 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: [auscope-geosciml] RE : RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
>  
> This does not solve the original issue.  The model (originally) says that the samplingFrame is a SamplingFeature, and when you defer the URI, you end up with a SKOS or OWL representation or whatever.  Unless those thing become valid representations for a SamplingFeature ?
>  
> If so, should I expect similar behavior from any xlink:href ?
> such as MappedFeature/specification ? - will
>  
> <gsml:specification xlink:href="http://example.com/surprise" xlink:role="http://sweet.jpl.nasa.gov/2.0/astroPlanet.owl#GeologicUnit"/>
>  
> be also valid ?  I would expect to be given a change to negociate the content type at least.
>  
> Eric
>  
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Guillaume.Duclaux at csiro.au
> Date: jeu. 2011-07-28 23:52
> À: auscope-geosciml at lists.arcs.org.au
> Objet : Re: [auscope-geosciml] RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> I agree with Simon regarding the fact the conceptual model should be conceptual.
> Simon proposed in his first email to make the SamplingFrame byReference. I think it is a good idea.
> 
> After some discussion, I believe GeoSciML should use the xlink:role to specify the nature of the representation of the SamplingFrame (defined byReference).
> 
> The XLink spec says that: "The value of the role (... )attribute must<http://www.w3.org/TR/xlink/#dt-must> be a URI reference as defined in [IETF RFC 2396]<http://www.w3.org/TR/xlink/#rfc2396> (...). The URI reference identifies some resource that describes the intended property. When no value is supplied, no particular role value is to be inferred. "
> 
> A schematron rule should enforce the use of xlink:role for the implementation.
> if the SamplingFrame is a SpatialSamplingFeature, the xlink:role URI should behttp://www.opengis.net/def/samplingFeatureType/OGC- OM/2.0/SF_SpatialSamplingFeature
> if the SamplingFrame is a SamplingFrameTermCode, eg. the earth surface, the xlink:role URI should point to a relevant concept in a vocabulary, eg http://sweet.jpl.nasa.gov/2.0/astroPlanet.owl#Geosphere
> 
> Although, could someone confirm that the constraint on the MappedFeature class {self.shape contained in SamplingFrame.shape} is not violated in the case the SamplingFrame is a term, as a term (call it controlled vocab if you want) doesn't have a spatial shape directly encoded in it.
> 
> My 2 cents...
> 
> Dr Guillaume Duclaux
> 
> Research Team Leader
> CSIRO Earth Science and Resource Engineering
> 
> Phone: +61 8 6436 8728  | Fax: +61 8 6436 8559  | Mobile:  +61 459 835 992
> 
> guillaume.duclaux at csiro.au<mailto:guillaume.duclaux at csiro.au> | www.csiro.au<http://www.csiro.au/> |
> Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151
> 
> PLEASE NOTE
> The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
> 
> Please consider the environment before printing this email.
> 
> 
> 
> 
> 
> On 29/07/2011, at 11:14 AM, <Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>> <Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>> wrote:
> 
> And the ╲term╡ is not just a free text field.  It is a href to a controlled vocabulary concept, the same as all the other href-to-controlled-vocabulary-terms that we have implemented throughout the model (at Simonâ•˙s suggestion).
> 
> 
> ________________________________
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfBruce.Simons at dpi.vic.gov.au<mailto:Bruce.Simons at dpi.vic.gov.au>
> Sent: Friday, 29 July 2011 12:46 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> In Edinburgh Clemens argued that with just an xlink the client would expect a spatial frame of reference somewhere in the resolved xlink.
> By explicitly indicating whether it is a sampling feature or a vocabulary term this expectation is removed.
> 
> ----------------------------------------------------
> Senior Information Systems Analyst
> Prospectivity & Exploration, Earth Resources Development Division
> IUGS-Commission for Geoscience Information Oceania Councillor
> Level 9, 55 Collins St
> PO Box 4440
> Melbourne, Victoria, 3001
> Australia
> 
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
> 
> 
> 
> From:        <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>
> To:        <auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>>
> Date:        29/07/2011 12:39 PM
> Subject:        Re: [auscope-geosciml] RE :  GeoSciML ready to do for        FullMoon [SEC=UNCLASSIFIED]
> Sent by:        auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au>
> ________________________________
> 
> 
> 
> We also should not be using ╢termsâ•˙ if they are just text fields.
> Not reliable, not interoperable.
> But if it is a URI, then there is no need for special treatment â•„ just use the xlinks.
> 
> The encoding rule is fine, _providing_ it enforces the use of URIs rather than text for ╢termsâ•˙.
> The conceptual model should say what it means.
> 
> Simon
> 
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
> Sent: Friday, 29 July 2011 10:29 AM
> To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
> Subject: [auscope-geosciml] RE : GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> Since Fullmoon will generate an XSD that will constrain us to either provide a real SamplingFeature or a term, this is the way to encode it.
> 
> do you disagree with the way XSD are generated or the conceptual model itself ?
> 
> Eric
> 
> 
> ________________________________
> 
> De: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> de la part de Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>
> Date: jeu. 2011-07-28 21:45
> Õ: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
> Objet : Re: [auscope-geosciml] GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> Tags and encoding rule are for implementation detail.
> Classes are for the conceptual model.
> The class diagram should show the conceptual logic.
> The last time I looked term-code was not a geologic concept.
> 
> I strongly disagree with the logic and decision here.
> 
> Simon
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfOliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
> Sent: Friday, 29 July 2011 9:44 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> Conceptually, I agree.  But implementation-wise, a value from a vocabulary (ie, ╲EarthSurface╡) is not a sams:SpatialSamplingFeature.
> 
> GeoSciML is more than just a conceptual model â•„ it is very much a logic implementation model too.  The UML model to XML schema is pretty much a 1-to-1 match, and we have here specifically stated how we want to implement the conceptual model.
> 
> 
> 
> Cheers,
> Ollie
> 
> 
> 
> ________________________________
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfSimon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>
> Sent: Friday, 29 July 2011 11:28 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> Yeah â•„ but it is a vocabulary-term that denotes a sampling-feature.
> So semantically it is a sampling feature.
> It is just a different representation (a rather limited one).
> 
> This is quite important. The model should show ╢whatâ•˙ in terms of the model, not in terms of some implementation artefact like a vocabulary term.
> ╢Vocabulary termâ•˙ has meaning in lexicography.
> ╢SpatialSamplingFeatureâ•˙ has meaning in mapping.
> Is this a model of a vocabulary, or of geological information?
> 
> Simon
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfOliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
> Sent: Friday, 29 July 2011 9:21 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> Hi Simon,
> 
> The model was byReference to a SpatialSamplingFeature, but in practice most instances were using a byReference to a vocabulary term, like ╲EarthSurface╡.  Considerable discussion at Edinburgh around what should be expected at the end of an xlink:href decided that if we model the href as a sampling feature, then the link should resolve to a sampling feature, not a vocabulary term.  The model now explicitly states that the link can be either to a sampling feature or to a vocabulary term.
> 
> Cheers,
> Ollie
> 
> _______________________________________________________________________
> 
> Ollie Raymond
> 
> Project Leader
> National Geological Maps and Data Standards Project<http://www.ga.gov.au/minerals/projects/current-projects/geological-maps-standards.html>
> Geoscience Australia
> 
> Interoperability Working Group<https://www.seegrid.csiro.au/wiki/bin/view/CGIModel/InteroperabilityWG>
> IUGS Commission for the Management and Application of Geoscience Information
> 
> Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
> Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email:oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au>  |  Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>
> _______________________________________________________________________
> 
> --- This message was created with 100% recycled electrons ---
> 
> 
> ________________________________
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfSimon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>
> Sent: Friday, 29 July 2011 11:04 AM
> To: auscope-geosciml at lists.arcs.org.au; Francois.Letourneau at RNCan-NRCan.gc.ca
> Subject: Re: [auscope-geosciml] GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> ╲For samplingFrame, we have created a union class which explicitly states that the samplingFrame association can be either a vocabulary term or a real SpatialSamplingFeature?<https://www.seegrid.csiro.au/wiki/bin/edit/CGIModel/SpatialSamplingFeature?topicparent=CGIModel.EdinburghModelAgendaAndNotes>. (DONE - OllieRaymond?<https://www.seegrid.csiro.au/wiki/bin/edit/CGIModel/OllieRaymond?topicparent=CGIModel.EdinburghModelAgendaAndNotes>, 22-7-2011) [Union class documentation on the TWiki at UmL2GMLAS<https://www.seegrid.csiro.au/wiki/bin/view/AppSchemas/UmL2GMLAS>]. Needs to be tested in Testbed instance docs.╡
> 
> Why not just make it ╢byReferenceâ•˙.
> Then the semantics are preserved even if there is not an instance in the correct format.
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfOliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
> Sent: Friday, 29 July 2011 8:49 AM
> To: Francois.Letourneau at RNCan-NRCan.gc.ca
> Cc: auscope-geosciml at lists.arcs.org.au
> Subject: [auscope-geosciml] GeoSciML ready to do for FullMoon [SEC=UNCLASSIFIED]
> 
> Hi Francois and all,
> 
> The trunk GeoSciML model and classmaps are now ready for FullMoon processing.  (Thanks to Gilly for helping with the classmaps)
> 
> This will be the final release candidate schemas for GeoSciML v3.  All the edits from Edinburgh have been done and we are on track for our release schedule (seehttps://www.seegrid.csiro.au/wiki/CGIModel/EdinburghModelAgendaAndNotes).
> 
> Cheers,
> Ollie
> 
> _______________________________________________________________________
> 
> Ollie Raymond
> 
> Project Leader
> National Geological Maps and Data Standards Project<http://www.ga.gov.au/minerals/projects/current-projects/geological-maps-standards.html>
> Geoscience Australia
> 
> Interoperability Working Group<https://www.seegrid.csiro.au/wiki/bin/view/CGIModel/InteroperabilityWG>
> IUGS Commission for the Management and Application of Geoscience Information
> 
> Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
> Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email:oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au>  |  Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>
> _______________________________________________________________________
> 
> --- This message was created with 100% recycled electrons ---
>  _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> 
> ã„∏â•Œ[1]È“{ch'â•ŒSLSNË”9CCâ⁄∑í≤Œí“ŸGñ⁄µ±N5;"Í–8ÔƒiÇ•&Nzf†ª|Ö˛gÉ˚É…'w讜í∑«bÚʧ~'^Ø˚ez*kzjw(*â≠˝ㄉã„∏â•Œ[1]Ú©jh~+luz趧╌uZ◊ˇ(kÆ–yß∑8Ô∑8ÔƒiÇ•&«aë–∑ê«…›®«–zw(ǧí∑§(*â≠˝h·SOñ⁄µ¿ÏπSNÈ“{aN57Ú±à«≈H+-êı”'&∫raz€¨r+jwkzj/zǬSOñ⁄µ¿ÏπSMí¸“í¸…âª˝"Í–*.fi–çı…íπ·í¶˘zf)fi®+W騶'ò¶˜¬zw^z€«é˚…W^ëı…◊«l2◊œjw]zË«&É…)ë˘¢æ«ºz-jë¡¢y€¨Ç˛i'꫖锢{az)ߢ*'ríª©fi¶)í∫«â•ŒSOó∂‰£S}â•Œ[1]Ê¥4óŸ´”,fi˘^jDz{"uê–∑ç§≤*èı§)í…¸-+â•ŒSOó∂‰£S}â•Œ[1]È“{oŸԧnÊ¿
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> 
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> 
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

-- 
Clemens Portele
portele at interactive-instruments.de
+49 228 9141073 (office)
+49 151 15298497 (mobile)

interactive instruments Gesellschaft für Software-Entwicklung mbH
Trierer Str. 70-72, 53115 Bonn, Germany
Geschäftsführer: Reinhard Erstling, Karla Hinzer, Clemens Portele, Bernd Weidner
Amtsgericht Bonn, HRB 3872



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110810/d9364744/attachment.htm>


More information about the GeoSciML mailing list