- From: Nicholas Car <nicholas.car@surroundaustralia.com>
- Date: Fri, 8 Jan 2021 12:21:25 +1000
- To: Paul Tyson <phtyson@sbcglobal.net>
- Cc: Michael Kifer <kifer@cs.stonybrook.edu>, Sandro Hawke <sandro@w3.org>, public-rif-dev@w3.org, geosparql.swg@lists.opengeospatial.org, cawelty@gmail.com
- Message-ID: <CAP7nqh2L8Ec7UPYzwKzxbJz6MQhRXYTkEpapVDSP8bavC4FVHQ@mail.gmail.com>
Hi Paul,
The GeoSPARQL specification, as put in 2012, "defines a set of RIF rules
that use topological extension functions defined ... to establish the
existence of direct topological predicates defined ... . One possible
implementation strategy is to transform a given query by expanding a triple
pattern involving a direct spatial predicate into a series of triple
patterns and an invocation of the corresponding extension function as
specified in the RIF rule."
It then gave a RIF Presentation Syntax template for the rules and listed
all the functions and predicates the rules should be created for, following
the template.
As far as I know, all implementers of GeoSPARQL - triplestore vendors and
open source projects - have implemented this logic internally, using
spatial data toolkits and custom functions. For example, GraphDB uses, I
think, Java open source spatial libraries to index GeoSPARQL literals and
then custom Java code to enable GeoSPARQL functions in their product to use
those indexes.
So, to date, GeoSPARQL has included the RIF information as a formalisation
of the reasoning that is elsewhere described in rules but I don't
believe anyone has used the RIF content, which only existed in template
form until now and isn't complete yet (see [1]). Further to this: the
GeoSPARQL rules are very simple, given the 1:1 relation of functions to
relations and the majority of effort vendors have to expend must surely be
in indexing geometry literals and linking spatial tools and triplestore
tools together in chains, not in rule implementation.
I guess the implication here is that RIF isn't critical path for GeoSPARQL
so we will probably just finish our GeosPARQL 1.0 Presentation Syntax
rules, update them to produce GeoSPARQL 1.1 rules and *maybe* produce rules
in RIF XML, but that's about it. It will be good to have well presented RIF
rules (in the correct syntaxes, available via persistent URIs, with correct
Content Negotiation) out there for a major standard though.
Cheers,
Nick
[1] https://github.com/opengeospatial/ogc-geosparql/pull/70
On Fri, Jan 8, 2021 at 5:27 AM Paul Tyson <phtyson@sbcglobal.net> wrote:
> I don’t know the GeoSPARQL use cases, but several years ago I had
> opportunity to write business data validation rules in RIF XML, then
> transform them (using xslt) to SPARQL, which was then run against an RDF
> dataset.
>
> Have you seen this presentation?
> http://www.polleres.net/presentations/20120913Datalog20_Tutorial.pdf. It
> includes discussion of SPARQL and RIF.
>
> I believe if you use RDF and need rules, RIF is the best choice because of
> its expressivity, extensibility, and good fit with other w3c standards. And
> there are many paths into and out of RIF XML using generic tool chains. But
> there is need for further harmonization among the standards.
>
> Regards,
> —Paul
>
> On Jan 6, 2021, at 19:03, Nicholas Car <nicholas.car@surroundaustralia.com>
> wrote:
>
>
> I think it would be possible, and pretty easy, to translate the
> Presentation Syntax document I've produced for GeoSPARQL into rif+xml. Not
> sure how much people will care since it's clearly not in use (because
> GeosPARQL hasn't provided it previously) but it might be good for posterity
> to have both the rif+xml & PS documents in the GeoSPARQL profile.
>
> I agree with Michael's point that it is "...too hard and error-prone to
> define the logical semantics for the XML syntax..." so I would just
> translate the PS that I have (after it's been validated by us in GeoSPARQL)
> into rif+xml, I wouldn't truy and create a comprehensive PS -> rif+xml
> converter!
>
> Our GeoSPARQL profile definition expects to communicate a format (Media
> Type or similar) for each artifact, so if we have both a PS & a rif+xml
> doc, it's still not clear to me what to put in for the PS.
>
> I think that if RIF is to be used, everyone hates XML these days so an RDF
> of custom, like PS, syntax is likely to be useful therefore a Media Type
> for it would be useful. I might use use the made-up "text/rifps" to start
> with and put in a note about it being made-up.
>
> Nick
>
>
> On Thu, Jan 7, 2021 at 10:38 AM Michael Kifer <kifer@cs.stonybrook.edu>
> wrote:
>
>> thanks Sandro. This reminded me what was the story behind the
>> presentation syntax (PS) etc.
>>
>>
>> PS was indeed not designed for transmission and what I write about
>> rifps+xml was obviously a nonsense.
>>
>> But it *was* formalized -- even more so than the XML syntax because the
>> semantics was defined in terms of the presentation syntax only.
>>
>> The semantics of XML was defined only by translation to the PS. The
>> reasons for this were:
>>
>> 1. It was deemed to be too hard and error-prone to define the logical
>> semantics for the XML syntax because it is so verbose and hard for humans
>> to understand.
>> 2. Because the presentation syntax is much more compact and easier to
>> understand, it was deemed useful as a guide to people who would want to
>> write exporters from their rule languages to RIF.
>> 3. Some WG members thought that someone might actually want use the
>> presentation syntax as an actual rule language.
>>
>>
>> - This was not an official position of the WG though.
>>
>>
>> The only officially RIF-sanctioned *transmission* syntax for machine
>> consumption is XML.
>>
>>
>>
>> --
>>
>> best,
>> --- michael
>>
>>
>>
>>
>> On 1/6/21 12:15 PM, Sandro Hawke wrote:
>>
>> On 1/6/21 5:14 AM, Nicholas Car wrote:
>>
>> Follow-up to the assertion about the use of "Probably rifps+xml":
>>
>> The appendix on RIF Media Type registration [1] states:
>>
>> "This media type [application/rif+xml] is intended to be shared with
>> other RIF dialects, to be specified in the future. Interoperation between
>> the dialects is governed by the RIF specifications."
>>
>> I find this hard to follow since Presentation and Abstract Syntaxes are
>> _not_ XML. Not sure what to do here. I will contact the original
>> proponent - Sandro Hawk - about this.
>>
>>
>> Turns out I was actually reading this thread!
>>
>> To my eye, it looks like I dropped the ball with the final IETF step on
>> getting rif+xml registered. I'm looking into how to best fix that now.
>>
>> On the Presentation Syntax, what I recall is that there's no media type
>> for it because it's not intended for interchange. The idea was you're
>> supposed to do the interchange using XML.
>>
>> I know it's a bit weird, but there was a decision made early on,
>> reflected in the charter
>> <https://www.w3.org/2005/rules/wg/charter.html#xml-syntax> text, "The
>> primary normative syntax of the language must be an XML syntax. Users are
>> expected to work with tools or rule languages which are transformed to and
>> from this format."
>>
>> (Other folks wanted things like N3 to be in-scope for the group, but that
>> wasn't the path selected during the chartering process.)
>>
>> In practice the PS was needed, but we didn't formalize the language very
>> thoroughly, and didn't debate the design nearly as much as we would have if
>> it were to be standardized for interchange. See:
>>
>>
>> - https://www.w3.org/2005/rules/wg/track/issues/56 Should the
>> presentation syntax have a simplied form in addition to the verbose form
>> - https://www.w3.org/2005/rules/wg/track/issues/77 Presentation
>> Syntax and how to express the test cases
>>
>>
>> These were easy issues because we knew the PS didn't matter very much.
>>
>> Does that make sense?
>>
>> If you want a media type for it now, I'm not sure the best path for that,
>> but I'm also looking into it.
>>
>> My apologies for getting the media-type registration process wrong, way
>> back when.
>>
>> -- Sandro
>>
>>
>> Nick
>>
>>
>> [1] https://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration
>>
>> On Wed, Jan 6, 2021 at 7:53 PM Nicholas Car <
>> nicholas.car@surroundaustralia.com> wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your response points. We will investigate validation with
>>> RIF4J if and only if we make further use of RIF than just this one document
>>> and the corresponding one for GeoSPARQL 1.1 we will surely produce.
>>>
>>> Regarding the Media Type "application/rif+xml": I make take it upon
>>> myself to register this, if we make wider use of RIF.
>>>
>>> Regarding your assertion that the Media Type for Presentation Syntax
>>> documents is "Probably rifps+xml", as in "application/rifps+xml", well it
>>> can't be since the Presentation Syntax is clearly not XML! It would perhaps
>>> have to be "text/rifps" or similar. If I take on the above, I make take on
>>> this one too.
>>>
>>> Regards,
>>>
>>> Nick
>>>
>>> On Wed, Jan 6, 2021 at 7:38 PM Michael Kifer <kifer@cs.stonybrook.edu>
>>> wrote:
>>>
>>>> Thanks for your email. Some answers within. Hope somebody else can fill
>>>> in the gaps in my answers.
>>>>
>>>>
>>>>
>>>> On 1/3/21 9:51 PM, Nicholas Car wrote:
>>>>
>>>> Dear RIF Dev Mailing list,
>>>>
>>>> We, the GeoSPARQL Standards Working Group, are updating the OGC's
>>>> GeoSPARQL specification, first published in 2012 which we refer to as
>>>> GeoSPARQL 1.0. We wish to better present the specification in
>>>> machine-readable form and to update it producing GeoSPARQL 1.1.
>>>>
>>>> GeoSPARQL 1.0 includes a template for a set of RIF rules [1]. We would
>>>> like to expand this template to produce a RIF artifact that can be included
>>>> in the set of GeoSPARQL 1.0 resources. We will also produce a GeoSPARQL 1.1
>>>> RIF artifact within the next few months.
>>>>
>>>> Please could you assist us with the following points:
>>>>
>>>> 1. Validity of our 1.0 RIF document
>>>> a. We have not been able to find any operating RIF validators
>>>> listed by the RIF WG [2] other than perhaps RIF4J [3]. Can you indicate
>>>> others, in particular, any that are online?
>>>>
>>>>
>>>> It seems that RIF4J is the only validator that is still available.
>>>>
>>>>
>>>>
>>>> b. Have any multi-format RIF validators been produced, specifically
>>>> for XML and Presentation Syntax?
>>>>
>>>>
>>>> See above.
>>>>
>>>>
>>>>
>>>> 2. Presentation of our 1.0 RIF document
>>>> a. The Media Type "application/rif+xml" is indicated for use for
>>>> RIF documents [4] but it is not registered with IANA's Media Types list
>>>> [5]. Can you clarify the status of the RIF Media Type?
>>>>
>>>>
>>>> This was the intent. The working group chairs were supposed to see to
>>>> it that the media types are registered, but apparently didn't.
>>>>
>>>>
>>>>
>>>> b. Assuming a RIF document in XML is to use the Media Type
>>>> "application/rif+xml" and the file extension ".rif", what should a
>>>> Presentation Syntax document use? Should it use ".rifps" for the file
>>>> extension, as per WG examples like [6] but then what Media Type?
>>>>
>>>>
>>>> Probably rifps+xml. Again, somebody was supposed to do it, but dropped
>>>> this task.
>>>>
>>>>
>>>> c. We intend to present the RIF artifacts for GeoSPARQL 1.0 and 1.1
>>>> online with persistent URIs that will resolve and communicate resource
>>>> Media Types via HTTP Content Negotiation. We could present multiple media
>>>> types for the same artifact (RIF in XML & Presentation Syntax). Does this
>>>> have precedent in the RIF community?
>>>>
>>>>
>>>> This sounds reasonable. I do not recall seeing a precedent though.
>>>>
>>>>
>>>>
>>>> Next I include a snippet of our RIF document below. It is highly
>>>> repetitive so I have only included the first 2 ForAll elements.
>>>>
>>>>
>>>> The snippet looks good.
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Michael Kifer
>>>>
>>>>
>>>>
>>>>
>>>> ----------
>>>> Document (
>>>> Prefix (geo <http://www.opengis.net/ont/geosparql#>)
>>>> Prefix (geof <http://www.opengis.net/def/function/geosparql/>)
>>>>
>>>> Group (
>>>> # geo:sfEquals
>>>> Forall ?f1 ?f2 ?g1 ?g2 ?g1Serial ?g2Serial (
>>>> ?f1[geo:sfEquals->?f2] :-
>>>> Or (
>>>> # feature – feature rule
>>>> And (
>>>> ?f1[geo:hasDefaultGeometry->?g1]
>>>> ?f2[geo:hasDefaultGeometry->?g2]
>>>> ?g1[geo:gmlLiteral->?g1Serial]
>>>> ?g2[geo:gmlLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> # feature – geometry rule
>>>> And (
>>>> ?f1[geo:hasDefaultGeometry->?g1]
>>>> ?g1[geo:gmlLiteral->?g1Serial]
>>>> ?f2[geo:gmlLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> # geometry - feature rule
>>>> And (
>>>> ?f2[geo:hasDefaultGeometry->?g2]
>>>> ?f1[geo:gmlLiteral->?g1Serial]
>>>> ?g2[geo:gmlLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> # geometry - geometry rule
>>>> And (
>>>> ?f1[geo:gmlLiteral->?g1Serial]
>>>> ?f2[geo:gmlLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> )
>>>> )
>>>>
>>>> # geo:sfEquals
>>>> Forall ?f1 ?f2 ?g1 ?g2 ?g1Serial ?g2Serial (
>>>> ?f1[geo:sfEquals->?f2] :-
>>>> Or (
>>>> # feature – feature rule
>>>> And (
>>>> ?f1[geo:hasDefaultGeometry->?g1]
>>>> ?f2[geo:hasDefaultGeometry->?g2]
>>>> ?g1[geo:wktLiteral->?g1Serial]
>>>> ?g2[geo:wktLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> # feature – geometry rule
>>>> And (
>>>> ?f1[geo:hasDefaultGeometry->?g1]
>>>> ?g1[geo:wktLiteral->?g1Serial]
>>>> ?f2[geo:wktLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> # geometry - feature rule
>>>> And (
>>>> ?f2[geo:hasDefaultGeometry->?g2]
>>>> ?f1[geo:wktLiteral->?g1Serial]
>>>> ?g2[geo:wktLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> # geometry - geometry rule
>>>> And (
>>>> ?f1[geo:wktLiteral->?g1Serial]
>>>> ?f2[geo:wktLiteral->?g2Serial]
>>>> External(geof:sfEquals (?g1Serial,?g2Serial))
>>>> )
>>>> )
>>>> )
>>>>
>>>> # repetition of the ForAll elements for all GeoSPARQL relations
>>>>
>>>> )
>>>> )
>>>> ----------
>>>>
>>>> Any further comments on our use of RIF would be greatly appreciated too!
>>>>
>>>> Regards,
>>>>
>>>> Nicholas
>>>> --
>>>> Dr Nicholas J. Car
>>>> Data Systems Architect
>>>> SURROUND Australia Pty Ltd
>>>>
>>>> GeoSPARQL QG member
>>>>
>>>> References
>>>> ---------------
>>>> [1] GeoSPARQL 1.0. http://www.opengis.net/doc/IS/geosparql/1.0. See
>>>> Clause 11, p 30.
>>>> [2] None of the other validators listed at
>>>> https://www.w3.org/2005/rules/wiki/Implementations seem to be online
>>>> other than perhaps RIF4J
>>>> [3] http://rif4j.sourceforge.net/
>>>> [4] https://www.w3.org/2005/rules/wiki/RIF_In_RDF#Namespaces
>>>> [5] https://www.iana.org/assignments/media-types/media-types.xhtml
>>>> [6]
>>>> https://www.w3.org/2005/rules/test/repository/tc/Class_Membership/Class_Membership-premise.rifps
>>>>
>>>>
>>>
>>>
>
--
______________________________________________________________________________________
kind regards
*Dr Nicholas Car*
Data Systems Architect at SURROUND Australia Pty Ltd
Address Level 9, Nishi Building,
2 Phillip Law Street
New Acton Canberra 2601
Phone +61 477 560 177 <++61+477+560+177>
Email nicholas.car@surroundaustralia.comWebsite
https://www.surroundaustralia.com
*Enhancing Intelligence Within Organisations*
*delivering evidence that connects decisions to outcomes*
[image: Australian-National-University-Logo-1 – ANU Centre for Water and
Landscape Dynamics]
*Dr Nicholas Car*
Adj. Senior Lecturer
Research School of Computer Science
The Australian National University
Canberra ACT Australia
https://orcid.org/0000-0002-8742-7730
https://cs.anu.edu.au/people/nicholas-car
Received on Friday, 8 January 2021 02:21:53 UTC