Open jeswr opened 2 years ago
The plan of the W3C N3 Community Group is to specify a core set of built-ins https://w3c.github.io/N3/files/builtin_spec.html We looked at FNO but it did not make it.
We looked at FNO but it did not make it.
Is there a discussion thread somewhere I can look at to see what lead to that decision
Yes there is in https://docs.google.com/document/d/1A3HAUhjaVnnJ6yVbFAvIBRJQjUY9aFlQ2_bGxkD0mnE/edit#
Meeting 31-August-2020
Present: Doerthe, Jos, Gregg, Hans, Jindrich Kollman, William
Doerthe: made example builtin descriptions
Doerthe: had long discussion with builtin (function ontology, FNO) person (Ben De Meester) on what can be done ; types of input / output
https://github.com/OpenRefine/OpenRefine/wiki/General-Refine-Expression-Language
https://fno.io/hub/search
https://docs.google.com/document/d/1TAOea3S_xbwnLrKL6snsN6VrsYxBA1Kw7DSHcvYgrK0/edit
Jos: how to deal with relations vs. functions? “Function” would return true or false
Doerthe: Ben can introduce a higher-level abstraction (param can be variable or concrete)
Doerthe: nice thing about FNO is that you can link your builtins to others (e.g., SPARQL)
Doerthe: could generate builtin code (e.g., for JS) based on ontology descriptions
Doerthe: but, perhaps a bit too complex for our current needs (slow us down)
Jos: can support flow patterns? .. (function can operate in either direction)
Doerthe: likes the interoperability aspect, but won’t help to describe functions in great detail
Doerthe: will likely be easier to write out the flow patterns in detail
Jos: RIF describes built-ins in an understandable, detailed way
Doerthe: aside from RIF, also look into GREL functions
William: FNO builtin descriptions could be parallel effort, but FNO would need to be adapted first ; let’s not let that delay us
Doerthe: yes, let’s start from RIF builtins
Jos: semantics need to state that all correct builtin inputs + outputs are logically true (these combinations will be infinite in most cases)
William: will “(1 2) math:sum 4 .” be true / false?
Jos: should not be possible to overrule semantics of builtin ; not even possible to state “(1 1) math:sum 2 .”
Doerthe: is the user always right (overwriting hell)? ..
Jos: basically an inconsistency ; should always throw an exception when builtin is referenced in an assertion ; = inference fuse
Cfr. “true -> false” = integrity constraint
(see https://github.com/w3c/N3/issues/9#issuecomment-477931299)
Gregg: should have a set of tests for this (inference fuse)
Jos: ok, adding a “true” builtin statement should not be an inconsistency (i.e., “(1 1) math:sum 2 .”) in theory, but it seems useless to allow it in practice
William: many more questions on builtins .. e.g., unifying a variable with a builtin IRI
Jos: should work perfectly - not an issue
(Doerthe & William wrote some examples on Skype chat)
Jindrich: plans on adding constraint satisfaction to his N3 reasoner
Doerthe: has seen people using builtins in unexpected places .. such as rule heads
William: so, currently focus on builtin descriptions a la RIF (not FNO, currently)?
Doerthe: yes, FNO thing would be very neat but not good for specifying what a function
Greg: let’s have weekly meetings?
William: yes, let’s do that
Consensus: builtin descriptions a la RIF (not FNO, currently)
Action point: formalize N3 builtin descriptions (Doerthe will reach out to Dominik)
Action point: send message on mailing list about weekly CG meetings
Action point: ask Jindrich about his reasoner!
@bjdmeest?
There has been some renewed interest in this, I'm following up in the mailing list https://lists.w3.org/Archives/Public/public-n3-dev/2022Aug/0002.html
This is a longer term reasoning iterop issue to handle complex reasoning use cases. It will also become a security challenge to implement for production environments after a research prototype is produced. For these reasons I suggest this issue is given a low priority for now.
Pitch
In order to do more expressive operations, reasoners often require built-ins. However, built-ins are often tied to a specific reasoner which reduces the interoperability.
Desired solution
Built-ins occuring in rules within solid should be dereferenable to a description that declaratively describes the built-in in a way that reasoners not implementing the built-in by default are able to generate the built-in on-the-fly based on the description.
Acceptance criteria
ex:add
,ex:concat
andex:skolem
; and use those functional descriptions to determine how to use those built-ins when they appear within N3Rules.ex:add
,ex:concat
andex:skolem
; and use those functional descriptions to determine how to use those built-ins when they appear within Proofs.Pointers