Re: Hello, n3

Agreed and looking forward to work with both of you Doerthe an William

-- https://josd.github.io/ <http://josd.github.io/>


On Wed, Dec 5, 2018 at 8:33 PM William Van Woensel <
william.vanwoensel@gmail.com> wrote:

> Hi all,
>
>
>
> If nobody else steps forward then I’d be willing to help out with the
> chairing part.
>
>
>
>
>
> W
>
>
>
> *From:* Gregg Kellogg <gregg@greggkellogg.net>
> *Sent:* December-04-18 3:11 PM
> *To:* Doerthe Arndt <doerthe.arndt@ugent.be>
> *Cc:* Dave Raggett <dsr@w3.org>; David Booth <david@dbooth.org>;
> public-n3-dev@w3.org
> *Subject:* Re: Hello, n3
>
>
>
> On Dec 4, 2018, at 8:54 AM, Doerthe Arndt <doerthe.arndt@ugent.be> wrote:
>
>
>
> Hi David, all,
>
> I volunteer since I really want to bring this forward. But I also never
> chaired such a group before and would be grateful if anyone else would
> co-chair. So, anyone else volunteering?
>
> +1. A group like this should mostly run itself, unless we decide to have
> calls, in which case the chair sets them up and moderates discussion.
>
>
>
> Gregg
>
> Kind regards,
> Doerthe
>
> Am 04.12.18 um 17:00 schrieb Dave Raggett:
>
> That should be easy enough to arrange - let me look into it.  I see that
> the CG lacks a Chair, and needs one to publish any reports. Anyone like to
> volunteer?
>
>
>
> On 4 Dec 2018, at 15:26, David Booth <david@dbooth.org> wrote:
>
>
>
> Excellent discussion!   I would suggest that we (as a group) start a
> github area with a github issues list, and start tracking these issues.
>
> Dave Raggett, is that something that you can initialize for the N3
> Community Group, within the W3C space on github?   And in case the question
> arises, I think it would make sense for it to be separate from the broader
> discussion of "how to make RDF easier to use", because this N3 effort is a
> very specific, focused effort, even though it is related.
>
> Thanks,
> David Booth
>
> On 12/4/18 5:56 AM, Doerthe Arndt wrote:
>
> Dear all,
> William and I - by accident - continued our discussion privately. Please
> find below the summary.
> Regards,
> Doerthe
> Hi Doerthe, all,
> Oops, that was by mistake .. I’m not used to replying on mailing lists,
> lol.
> //
> /If you don’t mind, I will try to summarize our conversation below—I think
> we’re pretty much in agreement on most issues. If you have no problems with
> it then feel free to forward (a summarized version?) to the mailing list.///
> • As an aside, I was wondering in what cases rules in consequences would
> be useful from a logical point of view (don’t have access to [1] right
> now). Isn’t the following just as effective:
> { ?C1 rdfs:subClassOf  ?C2, ?x a ?C1 } => ?x a ?C2
> But I understand why it could be (syntactically) useful from a
> pre-processing point of view—since only the initial rule body needs to be
> instantiated with TBox terms (?).
> > Yes, you can do that as well, but then the rules you use cannot be
> "automatically" written by the reasoner.
> /Indeed, that’s a pretty interesting aspect of it—the reasoner alone can
> instantiate the axioms based on the TBox. I will get around to reading your
> paper!/
> • As mentioned by Doerthe, and unbeknownst to me previously, N3 allows to
> describe statements directly using “formulae”, without having to explicitly
> “s-p-o-encode” the described statements, i.e.,
> { :william dc:wrote :Moby_Dick } a n3:falsehood .
> As also referenced by Doerthe, this very much reminded me of the work by
> Hartig et al., who introduced an extended semantics (RDF* and SPARQL*) [1]
> for reification support…
> > "The RDF semantic conditions do not place formal constraints on the
> meaning of much of the RDF vocabulary which is intended for use in
> describing containers and bounded collections, or the reification
> vocabulary intended to enable an RDF graph to describe RDF triples. This
> appendix briefly reviews the intended meanings of this vocabulary" (quote
> from: https://www.w3.org/TR/rdf11-mt/#whatnot)
> > In other words: it is not formally defined what rdf reification means.
> For sure—but it says the same thing about RDF containers and collections
> (and I hope we’re not going to skip representing those as well in N3!). I
> think that the intended meaning and the particular representation as
> defined in that section, is currently more or less taken as the standard
> way to deal with reification (e.g., it is also listed in the RDF primer).
> For instance, Hartig et al. define a syntax and semantics for a different,
> more usable reification representation; and present a conversion into this
> “standard” reification representation (in fact, as a way to support the
> model-theoretic interpretation of RDF*).
> > The general problem of reification is the rather unusual use of blank
> nodes: as you know, blank nodes already have a meaning, they are
> existentially quantified (and I hope that the discussion on the mailing
> list will not change that). So, the above means according to RDF semantics:
> "There exists a falsehood, this falsehood is a statement and has the
> subject "William", etc.") That is not the same as saying "The statement
> that William wrote Moby Dick is a falsehood.". This semantically rather big
> difference is a problem for the formal specification of reification and we
> have indeed the exact same problem (but in my opinion even worse) with
> lists and containers (by saying that a list *exists* you do not have the
> list).
> /Do you mean: having a more robust, formal definition of reification /
> lists / containers in place for N3, instead of building on the current
> (unformalized) method, would be a way forward? I’m not necessarily
> disagreeing here, but it could be a bit beyond our scope (?) Indeed, to me,
> there has always been this strange dichotomy between blank nodes being
> “existentially quantified” on the one hand (i.e., someone has an address,
> which has street X, etc.), and local identifiers on the other, where
> someone can actually reference this existential quantification elsewhere in
> the document (more like “existential variables” (?))./
> > N3 does not need these ugly constructs since it supports lists as "first
> class citizens" and has a construct for citation (the brackets {}). So, in
> practice I would add some rules making reification and first-rest-ladders
> "real" citations and lists and support only these "real" constructs in the
> mode theory. That would not exclude the use of them and by giving the rules
> we also give it the meaning you suggest here.
> /I think we’re in agreement here—the current way of representing lists and
> reification is quite ugly and, by adding well-defined constructs, we can
> make working with them much easier. But in the end, this meaning would be
> based on the “intended meaning” just like with Hartig et al./
> > I would be really careful with such "intended" meanings since that will
> cause misunderstandings.
> /Sure, but it’s unclear what else we could base ourselves on (?)/
> /> There are different logics which have the notion of context, like for
> example KIF, ISO Common Logic and MacCarthy's logic of context ( there are
> many more). We have to agree whether we want to have a higher order
> construct here (I would rather say no) or whether we want to model it as
> first order logic. I hope that will become clear if everyone also explains
> how he or she wants to use the concept./
> //
> • I believe there could be a semantic layer, aside from a syntactical one,
> that facilitates working with lists (i.e., RDF collections). For instance,
> when computerizing the OWL2 RL axiomatization, one often runs into the
> following types of rules:
> { ?c owl:unionOf ?l, ?l x:member ?cl } => ?cl owl:subClassOf ?c
> Where the x:member can be supported by adding an extra few rules [4].
> Using rdfs:member seems to do something similar for RDF(S) containers, but
> that’s much easier since containers do not represent linked lists.
>
> We should formalise built-ins: Cwm (and I think also the team
>
> submission) mentions a list of built-ins, you can find them at
> https://www.w3.org/2000/10/swap/doc/CwmBuiltins
>
> EYE supports even more built-ins. Some are taken from RIF, some are
>
> customized:
> http://eulersharp.sourceforge.net/2003/03swap/eye-builtins.html
> I hope that we as a group will be able to extend the list of N3 built-in
> predicates such that it won't be necessary for any reasoner to have such
> own predicates (but that is my vision for later).
> For sure—with an accompanying semantics, these built-ins / constructs /
> terms .. could be implemented consistently (and perhaps even without
> necessitating built-in support; e.g., by simply adding the corresponding
> axioms to the dataset?).
> • Even in case all list elements need to be referenced:
> { ?c owl:intersectionOf ?l, @forall :cl (?l x:member :cl, :cl a ?t, ?y a
> ?t) } => ?y a ?c
>
> Note that the rule above is problematic since the scope of your
>
> @forAll is basically the whole Web, so you can never know whether the
> antecedence of this rule is true. What you can do, is set a scope, saying
> something like "for all c1 mentioned in a certain document", this is
> something we can test.
> I had based this on your examples from your presentation (slides 12, 16; I
> don’t remember defining explicit scopes) but perhaps I’m wrong ...
>
> Your example would not work because it requires that whatever you find
>
> in the whole semantic we needs to be in the list ?l (@forAll :cl. ?l
> x:member :cl.). The reason for that is that the quantifier is in the
> antecedence of the rule. You basically say "if every cl is a member of l
> ... then" and not what you would like to have "for every member cl of l".
> /Note that I merely used this notation since I noticed it on your slides
> and it seemed to suit the purpose. But I understand your point—the
> universal quantification should be scoped to include only members of the
> list: /
> … Based on the rule you wrote, I think we could also go for local scoping
> here (so, mention a scope together with the universal quantifier), but
> maybe we should discuss that in the group (there could be better solutions).
> William
>
>
>
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
> W3C Data Activity Lead & W3C champion for the Web of things
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Dörthe Arndt
>
> Researcher Semantic Web
>
> imec - Ghent University - IDLab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems
>
> Technologiepark-Zwijnaarde 19, 9052 Ghent, Belgium
>
> t: +32 9 331 49 59 | e: doerthe.arndt@ugent.be
>
>
>