- From: Doerthe Arndt <doerthe.arndt@ugent.be>
- Date: Thu, 6 Dec 2018 12:37:15 +0100
- To: William Van Woensel <william.vanwoensel@gmail.com>, 'Gregg Kellogg' <gregg@greggkellogg.net>
- Cc: 'Dave Raggett' <dsr@w3.org>, 'David Booth' <david@dbooth.org>, public-n3-dev@w3.org
- Message-ID: <d909c30c-d277-8237-5ebf-ca5a6bd4b8cc@ugent.be>
Dear William, all,
@William: great to read that. I just added you as a chair.
To bring things forward, we should do two things now:
1. We should start our git repository to be able to exchange data.
2. We should initiate a first telephone conference to discuss the main
focus of our work.
For point 1: I saw that you can host your git repository on W3C (see
https://www.w3.org/community/about/tool/) but you need to ask for it.
Alternatively, we can host the repository somewhere else. I have no idea
what is the best practice there, therefore I ask you: where should we
host our git?
For point 2: I think it is best to "meet" after the holiday period and I
will set up a doodle for that, but I wondered about the best time slot:
I already know that William and I are sitting in different time zones
(CET and AST). But I do not know about the others: Could you please let
me know which other time zones I need to take into account?
Kind regards,
Doerthe
Am 05.12.18 um 20:32 schrieb William Van Woensel:
>
> 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
> <mailto: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
> <mailto: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 <mailto: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 <mailto:doerthe.arndt@ugent.be>
>
--
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
Received on Thursday, 6 December 2018 11:37:47 UTC