W3C home > Mailing lists > Public > public-powderwg@w3.org > March 2009

Re: Closure? (was Re: Request for two new media types submitted)

From: Eric Prud'hommeaux <eric@w3.org>
Date: Wed, 4 Mar 2009 16:16:38 -0500
To: Phil Archer <phila@w3.org>
Cc: Phil Archer <phil@philarcher.org>, Stasinos Konstantopoulos <konstant@iit.demokritos.gr>, Ivan Herman <ivan@w3.org>, Public POWDER <public-powderwg@w3.org>, Ralph Swick <swick@w3.org>
Message-ID: <20090304211638.GJ27505@w3.org>
On Wed, Mar 04, 2009 at 08:48:08PM +0000, Phil Archer wrote:
> OK, so no surprise that I got that wrong then.
> 
> If we go back to e-mail of last week[1], my question was, if we replace 
> the single sentence that is causing the problem with the one you 
> suggest, does anything else have to change? Does the rest of the #SE 
> block stay the same? The code Stasinos has written stays the same? But 
> what changes is that people who understand more about RDF than I do - 
> which is everyone on this thread - will be happy with the exception of 
> Stasinos?

i don't know of any other detractors. it would certainly satisfy me.

> Or does it mean that the whole of the SE section, i.e. the formal 
> mathematics, also has to change?

it seems like the formal semantics were written with the idea of a
semantic extension. so no change.

> Sorry to be so very far out of my depth but my concern, obviously, is to 
> resolve this and move on. If something is wrong, it needs changing. If 
> however the only member of the WG to understand this is unhappy, then 
> that's wrong too.

understood.

> What JJC wrote originally is at [2]. He said more afterwards (and came 
> to a f2f in Athens) but the basis is that e-mail.

JJC indicated that he was documenting the semantic extension. all seem
in agreement there.

> [1] http://lists.w3.org/Archives/Public/public-powderwg/2009Feb/0016.html
> [2] http://lists.w3.org/Archives/Public/www-archive/2007Dec/0042.html
> 
> Eric Prud'hommeaux wrote:
> >* Phil Archer <phil@philarcher.org> [2009-03-04 16:42+0000]
> >>Eric, Ivan, all,
> >>
> >>I've been looking at the semantics issue again and have discussed it
> >>further with Stasinos. This is my best shot at finding a resolution - by
> >>arguing that what we have now is correct.
> >>
> >>My understanding is that the debate is between:
> >>
> >>1. Applying the extension at the RDF layer
> >>2. Applying the extension at the application layer.
> >
> >Debate is between:
> >  1. RDF semantic extension (ericP)
> >  2. RDF core extension (Stasinos)
> >
> >This came up when I sought to clarify
> >[[
> > We extend RDF with the datatype properties ...
> >]] — http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE
> >and found that Stasinos considered it to not be a semantic extension.
> >
> >
> >>In POWDER's case the application is a reasoner and/or query engine:  
> >>POWDER documents assign metadata to sets of resources circumscribed by  
> >>IRI patterns. Semantically said, POWDER documents assert IRI  
> >>pattern-defined classes as being owl:subClassOf classes defined by  
> >>owl:RestrictionS.
> >>
> >>As currently documented and implemented, the WG took the advice of
> >>Jeremy Carroll and, lead by Stasinos in this area, followed the first
> >>option. This does not mean that we have extended RDF core outside the
> >>context of POWDER. RDF Semantics remain unchanged (so we're within our
> >>charter which states: "This working group is not chartered to make
> >>extensions to RDF core, neither is it chartered to research the broader
> >>development of the Semantic Web." [1]. Furthermore, we state at the very
> >>end of section 4.3 of the formal semantics doc:
> >>
> >>"Software can distinguish those RDF graphs to which the extended
> >>semantics apply by testing for the appearance of either the
> >>wdrs:matchesregex or the wdrs:notmatchesregex resource as the object of
> >>a triple. For instance, in Example 4-4 the following class description
> >>suffices to recognize a document that uses the semantic extension:" [2]
> >>
> >>Therefore we provide a clear and simple means for syntactically
> >>recognizing RDF graphs that need the POWDER extension to be fully
> >>understood.
> >>
> >>Furthermore, the POWDER extension monotonically adds meaning to RDF
> >>semantics, as no RDF vocabulary is affected.
> >>
> >>As a test of this, Stasinos created the SemPP engine using the
> >>TransOnto library [3]. This uses Jena and the Pellet Reasoner to process  
> >>POWDER-S documents. The key implementation being that Jena's API through  
> >>which a resource is added to the graph was overridden so that the  
> >>matchesregex triples appear in the graph. As a result, the DL reasoner  
> >>is unaffected, SPARQL queries are unaffected and, of course, other RDF  
> >>data is unaffected.
> >>
> >>Now, AIUI Eric's contention is that this is the wrong approach. A better
> >>way is to work at the application (OWL inference) layer. In this
> >>scenario, existing DL reasoners would not be useful, we'd need more  
> >>specific software. We are not averse to specific software (we have  
> >>defined and built two interoperable POWDER Processors that return RDF  
> >>descriptions of input URIs) but we are also informed by experience.
> >
> >I'm not arguing that that the implementation is the wrong approach,
> >but that the specification is actually describing a pretty ordinary
> >semantic extension. In support of that:
> >  1. [FPS] uses the language of semantic extesions [RS].
> >  2. wdrs:matchesregex stated to be an owl:DatatypeProperty (see [OR]).
> >  3. Defining wdrs:matchesregex as an extension to the RDF model would
> >     require duplicating the RDF Semantics, adding all possible
> >     interactions with wdrs:matchesregex .
> >
> >[PFS] http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE
> >[RS] http://www.w3.org/TR/rdf-mt/#ExtensionalDomRang
> >[OR] http://www.w3.org/TR/2004/REC-owl-ref-20040210/#Datatype
> >
> >>In 2004 - that long ago - many of the folk involved with POWDER now came
> >>up with a thing called RDF Content Labels [4]. It looks very much like
> >>POWDER, in that it has attribution, a means of putting labels in order
> >>and so on - all done with what looks superficially like RDF. Dan Bri
> >>often told me that RDF-CL is OK as long as what consumes it knows what
> >>to do with it. A general RDF tool kit certainly wouldn't make any sense
> >>of it. RDF-CL is a vocabulary defined to do a particular job, but is not
> >>a good citizen of the semantic web.
> >>
> >>Therefore, I would argue that we have in effect tried something very
> >>much like what Eric is suggesting. Indeed, that was what we were working
> >>towards right up until TPAC 2007 when I was going round asking anyone I
> >>could grab hold of how we solved the semantics issue. Take a look at the
> >>editor's note just above [5] where the question is laid out. This was
> >>the version of our main Description Resources doc we took to that TPAC
> >>meeting, fully expecting to be at CR by Christmas that year. Oh if only.
> >>Two people I asked went for the first option, two others for the second
> >>(from memory those 4 were you, Eric, Dan Bri, Fabien Gandon and Max  
> >>Froumentin).
> >>
> >>It was Tim who, given a choice of A or B, said "C, none of these"  and
> >>told us we should be using OWL classes, JJC who showed us how (with the
> >>semantic extension) and Stas who's proved that it works with minimal
> >>code.
> >
> >Did JJC write http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE ?
> >I note that it does have the suspicious fragment identifier "SE".
> >
> >>      It feels to me as if one reading of Eric's proposal would be to
> >>revisit a version of that original discussion. You'll understand my
> >>reluctance to do so.
> >>
> >>The reason it has taken us so long to get from there to where we are now
> >>is precisely because we've been trying to fit the square peg of matching
> >>URIs against patterns into the round hole of RDF with a minimum of  
> >>geometric distortion. I genuinely believe we have achieved that in the  
> >>current documentation and implementation.
> >>
> >>A new OWL datatype property is easier to document but it pushes POWDER
> >>into a silo where all software is specialist. The aim has always been to
> >>devise a means whereby a lot of triples that describe Web resources can
> >>be generated easily and processed as far as possible by existing
> >>software - hence the use of a barely-adapted Jena and wholly unchanged
> >>Pellet in SemPP.
> >>
> >>I hope I've understood both sides of the argument correctly?
> >>
> >>Taking all this into account, I am strongly inclined to leave the
> >>document as is when seeking the transition to PR.
> >>
> >>Cheers
> >>
> >>Phil.
> >>
> >>
> >>[1] http://www.w3.org/2007/02/powder_charter
> >>[2] Just above
> >>http://www.w3.org/2007/powder/Group/powder-formal/20090205.html#emptyIRIsets
> >>[3] http://transonto.sourceforge.net/
> >>[4] http://www.w3.org/2004/12/q/doc/content-labels-schema.htm
> >>[5] 
> >>http://www.w3.org/2007/powder/Group/powder-dr/20071102.html#basicQueries
> >>
> >
> 

-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 4 March 2009 21:16:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:14 GMT