RE: Hello, n3

Hi all,

 

+1 for using github & gitter.

 

I had a quick look through the Community Group policies <https://www.w3.org/community/about/agreements/>  and noted the following:

 

- Perhaps setting up initial operational agreements could be worthwhile—these craft the scope of the work, decision-making processes, communications preferences, and other operations, of the Community Group. 

 

- Regardless of our communication choice, all communications should be archived.

 

- With regards to meetings, the following should occur: the meeting is announced to the group in a timely fashion so that people can schedule attendance; an agenda is posted; meeting minutes are published, including topics discussions and decisions.

 

Yes, I’m in the Atlantic timezone (UTC-4h) ... This has previously complicated collaborations with the Old World, Lol. I’ll surely need a doodle to participate in a teleconference. 

 

 

W

 

From: Doerthe Arndt <doerthe.arndt@ugent.be> 
Sent: December-06-18 7:37 AM
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
Subject: Re: Hello, n3

 

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  <mailto:gregg@greggkellogg.net> <gregg@greggkellogg.net> 
Sent: December-04-18 3:11 PM
To: Doerthe Arndt  <mailto:doerthe.arndt@ugent.be> <doerthe.arndt@ugent.be>
Cc: Dave Raggett  <mailto:dsr@w3.org> <dsr@w3.org>; David Booth  <mailto:david@dbooth.org> <david@dbooth.org>; public-n3-dev@w3.org <mailto: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 <mailto:doerthe.arndt@ugent.be>