Re: Survey paper

Cory,

I think the end goal is to take SOS responses and transform those to RDF.
Meaning, we need to create a graph with triples  composed of Resource/
Property values. And, as we know Resources and Properties need be
represented via URIs. Values can take a URI or a literal value. So, we  need
to identify in SensorML and O&M  place holders for URIs. And we should use
those as starting point when building our graph. For example, UML
properties, xpath pointing to xlink attibutes, xpaths pointing to XML
elements ( like the one I described in a previous email),  or in the future
GML identifiers.

So... xlink is just one avenue..

-luis


On Thu, Aug 13, 2009 at 11:41 AM, Simon Cox <simon.cox@jrc.ec.europa.eu>wrote:

>  (1) If the point is to illustrate use of xlink for annotations, then you
> need to make sure that the example really does use xlink for this purpose.
> I'm not convinced that authorized GML xlink:**href** usage does this.
>
> xlink:role and xlink:arcrole might be OK, but there are very few examples
> in real-life (see
> https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/ObservationsAndSampling#Unknown_features for
> a pattern that has been used in the geoscience community).
>
> (2) As mentioned in my PS below, XLink has barely been implemented.
> So XLink semantics are essentially bound to to the small number of contexts
> where it has actually been used.
> RDDL and GML could be the most significant users (and yes, folks, GML is
> now seeing significant deployment, particularly under the auspices of
> GeoSciML/oneGeology and INSPIRE) so my story could be as good as it gets ...
>
>
> Simon
>
>
>
> Simon Cox
>
> European Commission, Joint Research Centre,
> Institute for Environment and Sustainability,
> Spatial Data Infrastructures Unit, TP 262
> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
> Tel: +39 0332 78 3652
> Fax: +39 0332 78 6325
> mailto:simon.cox@jrc.ec.europa.eu <simon.cox@jrc.ec.europa.eu>
> http://ies.jrc.ec.europa.eu/simon-cox
>
> SDI Unit: http://sdi.jrc.ec.europa.eu/
> IES Institute: http://ies.jrc.ec.europa.eu/
> JRC: http://www.jrc.ec.europa.eu/
>
>
>  ------------------------------
> *From:* public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org]
> *On Behalf Of *Cory Henson
> *Sent:* Thursday, 13 August 2009 17:28
> *To:* Simon Cox
> *Cc:* Laurent.Lefort@csiro.au; Michael.Compton@csiro.au;
> public-xg-ssn@w3.org
> *Subject:* Re: Survey paper
>
> I think this is a good discussion that we should continue, but as far as
> the survey paper is concerned there are two questions. (1) Should this be
> included as an annotation technique? There seems to be several groups using
> xlink as a 'model reference to an ontological description,' including also
> MMI/OOTethis (whether this is right or wrong, and these were discussed in
> ssn-xg meeting).  And second, (2) does XLink have a predefined translation
> to RDF (in rough equivalence to RDFa)?  And be aware we only have one page
> for this topic in the survey.
>
> thanks,
> -Cory
>
> On Thu, Aug 13, 2009 at 11:00 AM, Simon Cox <simon.cox@jrc.ec.europa.eu>wrote:
>
>>  PS - the whole xlink (and also xpointer) story is rather sad.
>> Going back to the dawn of XML (1997 or thereabouts in public forums) the
>> XML spec was supposed to have three legs:
>> XML Syntax
>> XML Linking
>> XML Transformations.
>>
>> Xlink was the last to emerage, and has barely been implemented anywhere.
>> Which is a shame because linking is the basis of the web.
>> And in the absence of a consensus on linking semantics, we are still
>> having discussion like this.
>>
>> Similarly xpointer - it is supposed to augment URI syntax by allowing
>> XPath expressions to point to fragments of resources - with a special
>> escape clause for # pointers which have gone by various names.
>>
>> We were perhaps over-eager/premature to adopt these technologies in the
>> GML spec (Laurent's EXAMPLE 3 below was my attempt to use the current state
>> of the confusing xpointer documentation). But the defense is that if we had
>> not adopted these external specs, we'd have had to invent something with
>> similar semantics ourselves. So we took the lazy programmers route and used
>> something already available (!) that looked right.
>>
>>
>>
>> Simon Cox
>>
>> European Commission, Joint Research Centre,
>> Institute for Environment and Sustainability,
>> Spatial Data Infrastructures Unit, TP 262
>> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>> Tel: +39 0332 78 3652
>> Fax: +39 0332 78 6325
>> mailto:simon.cox@jrc.ec.europa.eu <simon.cox@jrc.ec.europa.eu>
>> http://ies.jrc.ec.europa.eu/simon-cox
>>
>> SDI Unit: http://sdi.jrc.ec.europa.eu/
>> IES Institute: http://ies.jrc.ec.europa.eu/
>> JRC: http://www.jrc.ec.europa.eu/
>>
>>
>>  ------------------------------
>> *From:* Simon Cox [mailto:simon.cox@jrc.ec.europa.eu]
>> *Sent:* Thursday, 13 August 2009 16:52
>> *To:* 'Laurent.Lefort@csiro.au'; 'coryhenson@gmail.com'
>> *Cc:* 'Michael.Compton@csiro.au'; 'public-xg-ssn@w3.org'
>> *Subject:* RE: Survey paper
>>
>>  Thanks Laurent - I think your analysis is fairly complete.
>>
>> Regarding
>>
>>  > "Property metadata in GML ... overloading href, and use of other
>> xlinks" = 'model reference to a ontological description'
>> > https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/PropertyMetadata<https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/PropertyMetadata>
>>
>>  This was a proposal of mine, and does not yet have any formal status.
>> It was submitted to the currently active GML working group, but has not
>> been discussed yet.
>>
>> So 'composition by inclusion of remote resources'  is currently the only
>> authorized use of xlinks in GML.
>>
>>
>> Simon Cox
>>
>> European Commission, Joint Research Centre,
>> Institute for Environment and Sustainability,
>> Spatial Data Infrastructures Unit, TP 262
>> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>> Tel: +39 0332 78 3652
>> Fax: +39 0332 78 6325
>>
>> mailto:simon.cox@jrc.ec.europa.eu <simon.cox@jrc.ec.europa.eu>
>> http://ies.jrc.ec.europa.eu/simon-cox
>>
>> SDI Unit: http://sdi.jrc.ec.europa.eu/
>> IES Institute: http://ies.jrc.ec.europa.eu/
>> JRC: http://www.jrc.ec.europa.eu/
>>
>>
>>  ------------------------------
>> *From:* public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org]
>> *On Behalf Of *Laurent.Lefort@csiro.au
>> *Sent:* Thursday, 13 August 2009 16:39
>> *To:* simon.cox@jrc.ec.europa.eu; coryhenson@gmail.com
>> *Cc:* Michael.Compton@csiro.au; public-xg-ssn@w3.org
>> *Subject:* RE: Survey paper
>>
>>   Hi Cory,
>>
>> This is one of the trickiest parts of the paper. I'm on a steep learning
>> curve for RDFa and have scracthed my head before on xlink before but I'll
>> try to help.
>>
>> The way I would put it is:
>>
>> 1) xlink is almost the semantic equivalent in XML to void* pointers in C
>> programs - when you got one, you're not always sure what you can do with it
>> because the valid recipe to handle it will depends on the subset of xlink
>> use cases which are allowed (similarily, how to deal with void* in C
>> programs depends largely on the age of the captain. So, any solution which
>> does not propagate it is preferable.
>>
>> 2) If you have to use it, you need to look at the fine print to check
>> what the specs says:
>>
>> For example, in SVG, the xlink usage is described here:
>> http://www.w3.org/TR/SVG/linking.html
>>
>>
>> 3) In my opinion, the GML usage of xlink is incompletly described in
>> Section 8 of http://portal.opengeospatial.org/files/?artifact_id=20509
>>
>> Simon and other OGC colleagues posting on the seegrid wiki have
>> documented the xlink usage in GML in 2006 in two wiki pages which
>> corresponds to the two different use cases I think you are talking about:
>>
>> 'model reference to a ontological description' vs 'composition by
>> inclusion of remote resources'
>>
>> I think that:
>> GML Implementation of Features and Properties = 'composition by inclusion
>> of remote resources'
>> https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/GmlImplementation
>>
>> and:
>> "Property metadata in GML ... overloading href, and use of other xlinks" =
>> 'model reference to a ontological description'
>> https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/PropertyMetadata
>>
>> The major difficulty you should be aware of is that there are
>> several (subtly) different usages in of xlinks in usage in sub-communities
>> of OGC:
>> Xlink can be used to point to "fragment" of other XML or HTML files
>> (locatable through a # beacon declaration or with the help of  Xpath
>> expression)
>>
>> The GML spec authorises *4 variants*:
>>
>> EXAMPLE 1 A reference to an object element in the same GML document may be
>> encoded as:
>>
>> <myProperty xlink:href="#o1"/>
>>
>> EXAMPLE 2 A reference to an object element in a remote XML document using
>> the gml:id value of that object may be encoded as:
>>
>> <myProperty xlink:href="http://my.big.org/test.xml#o1"/>
>>
>> EXAMPLE 3* A reference to an object element in a remote XML document (or
>> GML object repository) using the gml:identifier property value of that
>> object may be encoded as:
>>
>> <myProperty xlink:href="http://my.big.org/test.xml#element(//gml:GeodeticCRS[./gml:identifier[@codeSpace="urn:x-ogc:def:crs:EPSG:6.3:"]="4326"])"/>
>>
>>
>> *Personally, I have never seen anyone which uses this XPath
>> augmented style of uris ...
>>
>> EXAMPLE 4 A reference to an object element with a uniform resource name
>> may be encoded as follows (note that a URN resolver is required to resolve
>> the URN and access the referenced object):
>>
>> <myProperty xlink:href="urn:x-ogc:def:crs:EPSG:6.3:4326"/>
>> These 4 examples correspond to a first case of  'composition by inclusion
>> of remote resources'
>>
>> One issue is that the GML specification let the door open to all the
>> possibility defined by the XLink spec through this sentence "the most
>> useful of these [xlink attributes] are" .... and "For complete
>> definitions of these and other Xlink components, including their use in
>> extended Xlink association maps, refer to the Xlink specification."
>>
>> This GML xLink Profile (07-083) by Andrew Woolf
>> http://epubs.cclrc.ac.uk/bitstream/1851/AWO%20-%20xlink.ppt describes how
>> some of these xlink attributes should be used in GML for a small sets of
>> specific use cases. It has also been proposed around 2006 but to my
>> knowledge it has not been approved or recyled in a formally approved GML
>> spec. probably because it corresponds to a specific use case, when xlink are
>> used to locate resources embedded in netCDF files.
>>
>>
>> *I have to rush a bit here because you have exchanged 3 messages since I
>> have started to type. *
>>
>> I think that the usage of xlink in SWE may be different and = 'model
>> reference to a ontological description'
>>
>> This is a different case because the xlink pointer is no longer used
>> to point to something which would corresponds to a RDF instance (container
>> of data) but rather to what would be a property of a class in the ontology
>> (or in a UML model).
>>
>> 4) Different types of URIs
>>
>> Long story (another post needed). For better scoped definitions, see the
>> skos notation or the CURIEs spec.
>>
>> 5) Source of confusion (in general and in the paper)
>>
>> There are many possible combinations of the above usage. You are
>> introducing a new one which is to use xlink for annotations.
>>
>> Question: do you want to attach an annotation to a block of XML file which
>> could have been replaced by a xlink pointer for the purpose of 'composition
>> by inclusion of remote resources'  (e.g a gml:Point) or a block of the
>> XML file which is a  'model reference to a ontological description' vs
>> 'composition by inclusion of remote resources'
>> (e.g. a swe:Phenomenon). I think to you should have different mappings for
>> the two cases.
>>
>> 6) To be continued ...
>>
>> Laurent.
>>
>> PS: The GML spec says page 20:  GML follows RDF (W3C, 1999) *terminology*and uses the term property rather than attribute or association role.
>> This translates to something like: some of the names of class or
>> attributes used in GML have been borrowed from RDF.
>>
>> But not to something like: When the user find a RDF-like concept in GML,
>> he can be confident that the semantics of the corresponding concept or role
>> in the RDF specs are applicable to it.
>>
>>
>>  ------------------------------
>> *From:* public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org]
>> *On Behalf Of *Cory Henson
>> *Sent:* Thursday, 13 August 2009 14:27
>> *To:* Simon Cox
>> *Cc:* Michael.Compton@csiro.au; public-xg-ssn@w3.org
>> *Subject:* Re: Survey paper
>>
>> Hi Simon,
>>
>> Thanks for the comment.  We are using the term semantic annotation as
>> described in SAWSDL, as a model reference to a ontological description.
>> Does this conflict with the description as a 'composition by inclusion of
>> remote resources'? As far as mapping to RDF, this is in comparison to RDFa
>> which has a known syntactic translation from the set of annotations to RDF
>> triples. While xlink:href maps to rdf:resource, how would the values of
>> properties of this resource be translated to RDF? If this is not correct, or
>> the wording is awkward, please point us in the right direction.  Thanks for
>> your help.
>>
>> -Cory
>>
>>
>> On Thu, Aug 13, 2009 at 8:01 AM, Simon Cox <simon.cox@jrc.ec.europa.eu>wrote:
>>
>>> Hi Mike -
>>>
>>> A clarification relating to semantic annotations and xlink:
>>>
>>> In GML-style XML documents, xlink:href plays the same role as
>>> rdf:resource
>>> in an RDF/XML document.
>>> I.e. it holds a pointer to external resource, which could be pasted
>>> inline
>>> as an anonymous node with equivalent semantics.
>>> This is a basic GML pattern and is explained in the GML spec
>>> http://portal.opengeospatial.org/files/?artifact_id=20509 clause 7.2.3.
>>> The examples involving xlink:href in Figure 2 aren't exactly
>>> 'annotations',
>>> more 'composition by inclusion of remote resources'.
>>>
>>> So I'm not sure if the example supports the point you are making.
>>>
>>> You comment 'XLink has no predefined mapping to RDF.'
>>> As mentioned above, _as used in GML documents_ xlink:href maps to
>>> rdf:resource.
>>>
>>> Simon Cox
>>>
>>> European Commission, Joint Research Centre,
>>> Institute for Environment and Sustainability,
>>> Spatial Data Infrastructures Unit, TP 262
>>> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>>> Tel: +39 0332 78 3652
>>> Fax: +39 0332 78 6325
>>> mailto:simon.cox@jrc.ec.europa.eu
>>> http://ies.jrc.ec.europa.eu/simon-cox
>>>
>>> SDI Unit: http://sdi.jrc.ec.europa.eu/
>>> IES Institute: http://ies.jrc.ec.europa.eu/
>>> JRC: http://www.jrc.ec.europa.eu/
>>>
>>> -----Original Message-----
>>> From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org]
>>> On
>>> Behalf Of Michael.Compton@csiro.au
>>> Sent: Thursday, 13 August 2009 13:43
>>> To: public-xg-ssn@w3.org
>>> Subject: Survey paper
>>>
>>> Hi all,
>>>
>>> Sorry it's so close to the SSN'09 deadline, but with help from Cory and
>>> Holger, I (finally) have a survey paper.  Please read, comment, etc.
>>>
>>> (there are a couple of obvious tweaks/FIXME's yet to be made)
>>>
>>> Michael
>>>
>>>
>>>
>>
>>
>> --
>> Cory Andrew Henson
>> Kno.e.sis Center, Wright State University
>> http://knoesis.wright.edu/researchers/cory/
>>
>
>
>
> --
> Cory Andrew Henson
> Kno.e.sis Center, Wright State University
> http://knoesis.wright.edu/researchers/cory/
>



-- 
Luis Bermudez Ph.D.
Coastal Research Technical Manager
Southeastern Universities Research Association (SURA)
bermudez@sura.org - Office: (202) 408-8211
1201 New York Ave. NW Suite 430, Washington DC 20005