Re: Comments on Last-Call Working Draft of RDF 1.1 Semantics

Antoine, this was not the question; my apologies if I was not clear.

At this point in time and process what I am interested in is the nature of the change of the _current RDF 1.1 CR documents_ in case the WG agrees to change it the way you and Michael advocate it.

Ivan 




On 10 Dec 2013, at 13:41 , Antoine Zimmermann <antoine.zimmermann@emse.fr> wrote:

> Although the change is not editorial in my opinion (and certainly in Michael's opinion), it does not require more testing of reasoners because it does not change entailments. The current phrasing has been tinkered precisely with this goal in mind.
> 
> However, it changes the compatibility of the designs of existing specifications, meticulously tested and agreed upon with datatype maps, as well compatibility with any document ever published about datatype reasoning on the semantic web.
> 
> By having a design that is not formally complying with what's in OWL, SPARQL and RIF, the current version practically imposes any future OWL WG, SPARQL WG or RIF WG to revise their specs according to the new definition, even if they disagree with this design (or, if they don't revise, they maintain a divergence of definitions that is very much detrimental to spec ecosystem).
> 
> 
> AZ.
> 
> Le 10/12/2013 11:00, Ivan Herman a écrit :
>> Without taking any sides here, just trying to understand where we
>> are: how would the proposed changes affect existing implementations,
>> test suites, etc. Putting another way: would a change back to the
>> 2004 formulation invalidate current implementation results, ie, the
>> CR phase; would it actually mean a new design concept? (New in the
>> sense of the current document.)
>> 
>> Obviously, this question relates on how to move forward. There are
>> three possible approaches:
>> 
>> - The changes are editorial, they do not affect the current test
>> suite and implementation results and they do not represent a design
>> change; as a consequence a change (if accepted by the WG, of course!)
>> would not jeopardize going to PR very soon. - The changes would
>> require a new testing phase. That means a 2nd Last Call would be
>> required, meaning that the documents cannot go to PR before the end
>> of January by my rough calculations, ie, the final recommendations
>> would be published end of February-early March - The changes
>> represent a major design change, meaning that we have to go back to
>> 2nd Last Call and proceed from there. That would add another 3-4
>> weeks to our schedules
>> 
>> Again, this is not taking sides in the discussion, this is just
>> clarifying what the effect of a change would be on our timeline. I do
>> not think I have enough knowledge and understanding of the issues to
>> answer these questions.
>> 
>> Ivan
>> 
>> 
>> 
>> On 10 Dec 2013, at 10:22 , Antoine Zimmermann
>> <antoine.zimmermann@emse.fr> wrote:
>> 
>>> Michael, all,
>>> 
>>> 
>>> I want to express myself on this issue, as it reiterates a debate
>>> in which I took an active and passionate part. I have pondered this
>>> quite a lot recently and this email is the result of a thorough
>>> examination of the problem.
>>> 
>>> I believe that this working group has handled this issue very
>>> badly, and I include myself here. My mistake was to finally vote in
>>> favour of the publication of RDF 1.1 Semantics as a LCWD with its
>>> current treatment of D-entailment. I did it in the interest of
>>> moving forward but I regret it now. I never liked the change and
>>> still find it terrible, all the more so that it is totally
>>> unnecessary.
>>> 
>>> Here is my position now: - I completely agree with everything that
>>> Michael says and I find the arguments very compelling; - I request
>>> one last time that concepts and semantics reintroduce the notion of
>>> datatype map in its formal definitions (I can detail all the
>>> changes that need be made); - I will support Michael's formal
>>> objection by issuing my own formal objection if the documents go
>>> into PR with the current design.
>>> 
>>> This may seem a very late decision that would have required some
>>> more discussion, but anyone who has followed the earlier
>>> discussions should be aware that all the arguments have already
>>> been exposed, the WG has been warned about the issue in June and
>>> refused to apply the simple and straightforward solution of simply
>>> keeping datatype maps. The WG was clearly motivated to publish in
>>> LC in spite of the objection anyway.
>>> 
>>> Note that I never accepted that it is an editorial issue. It is
>>> doubtful that the editors believe it to be editorial, considering
>>> the vehemence with which they defend the design.
>>> 
>>> Michael, here is a piece of the story: the change has been made to
>>> RDF 1.1 Semantics editor's draft without prior discussion, without
>>> any issue raised, without any formulated desire to do so. Even RDF
>>> 1.1 Concepts still contained the concept of a datatype map for
>>> quite some time (3 months) after the change was introduced. When I
>>> expressed concern about this new design, Pat retrospectively
>>> presented datatype map as an important problem in RDF 1.0. Like
>>> you, Michael, I have never seen anybody expressing concern in any
>>> way about datatype map. Please take a look at
>>> http://lists.w3.org/Archives/Public/public-rdf-wg/2013Apr/0133.html
>>> and following emails in the thread for additional discussions in
>>> the WG.
>>> 
>>> I would like that the WG do not act foolishly by allowing the
>>> publication of an unnecessary change that will generate both an
>>> internal and an external formal objection. Only Pat is expressing
>>> his view in the conversation with Michael. Peter, the WG chairs,
>>> W3C staff should examine Michael's arguments very carefully.
>>> 
>>> We are not in a deadlock like with dataset semantics. There is a
>>> simple and non-contentious way out of the situation. A solution
>>> using datatype maps cannot generate a serious formal objection,
>>> since the arguments against it would be quite ridiculous.
>>> 
>>> 
>>> Best, AZ.
>>> 
>>> Le 09/12/2013 23:15, Michael Schneider a écrit :
>>>> Pat,
>>>> 
>>>> you are the only one whose mails tend to be even longer than
>>>> mine. This change must really be extremely important to you to
>>>> get it in, after so many years of everyone else apparently being
>>>> happy with the original definition. But I hear you saying below
>>>> that the problem "had been widely noted", and I guess that
>>>> everyone probably just waited for the next RDF WG to finally make
>>>> the change. Too sad, that no one ever told me all the time, not
>>>> even when I have been a "Semantics editor" myself...
>>>> 
>>>> Anyways, I think, all points have been made. I have made mine, at
>>>> least, and will stick with them. There will be no further
>>>> involvement into the discussion from my side, except for
>>>> answering concrete requests, e.g. for clarification, etc. It's
>>>> now up to the WG to make a decision. What I can say is that if
>>>> this change makes it into PR, I'm going to formally object, and
>>>> my basic line of argumentation should be clear by now.
>>>> 
>>>> Best, Michael
>>>> 
>>>> Am 09.12.2013 10:07, schrieb Pat Hayes:
>>>>> More (unofficial) replies from me. -Pat
>>>>> 
>>>>> On Dec 8, 2013, at 2:28 PM, Michael Schneider <schneid@fzi.de>
>>>>> wrote:
>>>>> 
>>>>>> Hi Richard!
>>>>>> 
>>>>>> Am 07.12.2013 02:52, schrieb Richard Cyganiak:
>>>>>>> Hi Michael,
>>>>>>> 
>>>>>>> An unofficial response from the sidelines. I always make a
>>>>>>> fool of myself when I comment on Semantics matters, so I’m
>>>>>>> already regretting this email.
>>>>>> 
>>>>>> Very good that you step into this discussion, as you are one
>>>>>> of the editors of the RDF Concepts document, and I haven't
>>>>>> had realized yet that my points hit this document as well.
>>>>>> 
>>>>>>> But doesn’t
>>>>>>> http://www.w3.org/TR/rdf11-concepts/#datatype-maps answer
>>>>>>> your concern? It says that XSD IRIs MUST denote their
>>>>>>> respective datatypes. This is a normative for Semantics.
>>>>>> 
>>>>>> But what about all the other, non-XSD datatypes, that are
>>>>>> around (in OWL and elsewhere) or that can be invented as
>>>>>> custom datatypes (e.g. a datatype for representing complex
>>>>>> numbers)? What does the "MUST denote their respective
>>>>>> datatypes" mean then?
>>>>> 
>>>>> It means, the IRI that is used to identify that datatype must
>>>>> indeed uniquely identify it, and be understood to so identify
>>>>> it throughout any RDF processing which involves that datatype
>>>>> IRI, i.e., in brief, it must be what is called an "identifier"
>>>>> in a large swathe of Web specifications and recommendations and
>>>>> TAG discussions.
>>>>> 
>>>>>> In the RDF 2004 spec, this was perfectly clear: once you
>>>>>> have provided an explicit datatype map D, i.e. a set of pairs
>>>>>> <aaa,x> of datatype IRIs aaa and their respective datatypes x
>>>>>> (the latter, for example, given in terms of a pointer to
>>>>>> another specification that defines that datatype)
>>>>> 
>>>>> This is exactly the same situation we have with the new
>>>>> description. Once you are provided with a datatype IRI which
>>>>> identifies a datatype (as you say, typically given in terms of
>>>>> a pointer to another specification; indeed, typically this
>>>>> pointer is the root IRI of the datatype IRI itself) then the
>>>>> "datatype map" is fixed. Indeed, this datatype map is simply
>>>>> the interpretation mapping of that datatype IRI, if we require
>>>>> (as we do in the semantic condition) that D-interpretations
>>>>> must interpret 'recognized' IRIs (those in D) to denote the
>>>>> datatypes they identify.
>>>>> 
>>>>>> , then the "General semantic conditions for datatypes", as
>>>>>> defined in the old spec, would do the rest for you, e.g. the
>>>>>> first of these semantic conditions is:
>>>>>> 
>>>>>> "if <aaa,x> is in D then I(aaa) = x"
>>>>>> 
>>>>>> To be read as: "the datatype IRI aaa denotes its 'respective
>>>>>> datatype' x."
>>>>> 
>>>>> Exactly. But notice what the 2004 description does: it
>>>>> introduces a new, unmotivated and *arbitrary* mapping from IRIs
>>>>> to values, then insists that the interpretation mapping be
>>>>> identical to this new mapping on datatype IRIs. All this
>>>>> amounts to is exactly what you just said: the datatype IRIs
>>>>> *denote* their respective datatypes. So the 2013 description
>>>>> starts with this idea: we *assume* that the vocabulary D has a
>>>>> fixed interpretation in which each IRI *denotes* a datatype. A
>>>>> D-interpretation is then just an interpretation which extends
>>>>> this fixed interpretation of D. This is no more nor less
>>>>> arbitrary or undefined than the 2004 description, in which the
>>>>> datatype map was arbitrary: it simply hands over to some
>>>>> external authority the task of assigning the interpretation of
>>>>> datatypes to IRIs. Which, as I tried to explain in more detail
>>>>> in my previous email response to you, reflects the actual
>>>>> reality of how datatypes are assigned to IRIs on the Web. And
>>>>> the 2013 way of describing t
>>>> his is simpler, because it does not introduce a new concept and
>>>> immediately discard it in favor of an interpretation mapping, but
>>>> talks throughout in terms of interpretations of IRIs.
>>>>> 
>>>>>> Now, indeed, the old form in its generality allowed for
>>>>>> defining datatype maps where an XSD IRI is mapped to some
>>>>>> datatype which is not the corresponding XSD datatype. Neither
>>>>>> do I see this as a problem (it's like as you can write
>>>>>> non-terminating or "non-intuitive" programs in any
>>>>>> programming language), nor can such "evil" stuff be excluded
>>>>>> entirely, anyways.
>>>>> 
>>>>> I agree it is not a major problem in practice, but it is a flaw
>>>>> in the specifications. Your analogy with unintuitive programs
>>>>> is beside the point. Of course we cannot prevent users writing
>>>>> crazy RDF, but this was a craziness in the *specification*, not
>>>>> in user-written RDF.
>>>>> 
>>>>>> As I have pointed out in my original mail, you can associate
>>>>>> any XSD URI with any other datatype easily as soon as you
>>>>>> have equality in your entailment regime, i.e., owl:sameAs.
>>>>> 
>>>>> It is only an aside, but I think this is not correct. The RDF
>>>>> specs refer to the XSD specs, and the XSD specs state what it
>>>>> is that the XSD IRIs refer to. So, any owl:sameAs assertion
>>>>> which has the OWL consequence that such an IRI refers to
>>>>> something other than what XSD says it does, is inconsistent
>>>>> according to the OWL+RDF specs. An inconsistent assertion does
>>>>> not associate anything to anything.
>>>>> 
>>>>>> Of course, with the restriction given above, this would then
>>>>>> easily lead to unsatisfiable RDF graphs, if the value spaces
>>>>>> of the datatypes are disjoint (as it is the case for, e.g.,
>>>>>> xsd:string and xsd:integer).
>>>>> 
>>>>> My point above does not rely on the disjointness of the value
>>>>> spaces. XSD asserts that the datatypes themselves are pairwise
>>>>> distinct.
>>>>> 
>>>>>> But in any way there is no method to stop people from doing
>>>>>> crazy stuff.
>>>>> 
>>>>> But we can have specs which say when they are being
>>>>> inconsistent, as we do when the write an ill-typed literal.
>>>>> 
>>>>>> And as I said, I don't consider this not to be a problem at
>>>>>> all, let people fool around if they like, I don't have to buy
>>>>>> their stuff. And you have this option
>>>>> 
>>>>>> of fooling around in virtually any (non-trivial) technology,
>>>>>> e.g. in programming languages, but no one ever complains.
>>>>>> 
>>>>>> But if the Working Group believes that it is still a good
>>>>>> idea to include such a restriction on XSD datatype IRIs, then
>>>>>> just add a sentence corresponding to the above one to the
>>>>>> spec:
>>>>>> 
>>>>>> "Given a datatype map D and a mapping <aaa,x> in D, then if
>>>>>> aaa is an XSD IRI, then x MUST be the respective datatype (as
>>>>>> defined in the XSD spec)."
>>>>> 
>>>>> Both the 2004 and 2013 documents already make this imposition.
>>>>> But look at how they do it. In the 2013 version, it says that
>>>>> RDF must conform to the XSD specifications of what the XSD
>>>>> datatype IRIs mean. This is simply a reinforcement of what all
>>>>> Web users expect, the standard way to determine meanings of
>>>>> IRIs on the Web. The 2004 version said that there is a new,
>>>>> special, kind of mapping (different from an interpretation map)
>>>>> which applies only to IRIs denoting datatypes; that this map
>>>>> must be defined, but its only purpose is that D-interpretations
>>>>> must agree with it; and in the XSD case, it must map each XSD
>>>>> IRI to the datatype that the XSD spec says it identifies. So
>>>>> there is a map which agrees with the XSD specs and the
>>>>> D-interpretation agrees with that map. Which is just a more
>>>>> complicated way of saying what the 2013 specs say, but in
>>>>> non-standard terminology and using a construct which is neither
>>>>> intuitive nor necessary. The complication introduced by the
>>>>> 'datatype map' serv
>>>> es no useful function.
>>>>> 
>>>>>> Then, you have the restriction that you want, without the
>>>>>> need to change the original representation formalism for
>>>>>> datatype semantics - the two things, datatype maps and
>>>>>> restrictions on datatype IRIs, have really nothing to do
>>>>>> which each other. Personally, I would be ok with this
>>>>>> treatment (knowing well that I can still happily garble up
>>>>>> the whole datatype semantics with owl:sameAs ;-)).
>>>>>> 
>>>>>>> Can’t specs that currently use datatype maps in their
>>>>>>> formalism simply continue to do so? They just need to state
>>>>>>> that the IRIs in the datatype map are considered recognized
>>>>>>> datatype IRIs (to be technically compatible with RDF 1.1
>>>>>>> Semantics), and add a requirement that certain datatype
>>>>>>> IRIs, if present in a datatype map, MUST be paired with
>>>>>>> certain datatypes (to be compatible with 1.1 Concepts).
>>>>>>> It’s not like RDF 1.1 is outlawing the datatype map
>>>>>>> construct. It just doesn’t use it to define its own
>>>>>>> semantics.
>>>>>> 
>>>>>> Well, other specs may perhaps continue to use datatype maps,
>>>>>> but then imagine what an embarrassment this would be for the
>>>>>> RDF WG: by going on with the old datatype maps even in the
>>>>>> next spec, the other spec's WG would clearly confirm that it
>>>>>> prefers the old way over the new way, so the old way has
>>>>>> always been good enough for that spec, while the new one is
>>>>>> not good enough to switch to it. Another round of spec wars
>>>>>> in the SW...
>>>>> 
>>>>> Oh, bullshit. I fully expect that future spec WGs will find the
>>>>> 2013 treatment of datatypes clearer and simpler than the 2004
>>>>> treatment and will use it in preference. If they wish to go on
>>>>> using the term "datatype map' for a D-interpretation mapping
>>>>> restricted to datatype IRIs, the only embarrassment I will feel
>>>>> is a slight sense of regret that I was so lazy as to have
>>>>> introduced the clumsy term in 2004.
>>>>> 
>>>>>> But I think there may be a general misunderstanding here of
>>>>>> what I am about primarily. I'm not in the first place
>>>>>> interested in the question whether the particular proposed
>>>>>> change is appropriate or not (although I consider it to be
>>>>>> confusing, awkward, and a bad idea). What I am primarily
>>>>>> about is that there is no need for any change whatsoever!
>>>>> 
>>>>> The hallmark of significance used by the WG  for changes to
>>>>> RDF semantics has always been, does it change any entailments?
>>>>> And this does not. It is purely a change in the *style of
>>>>> description* of the semantics, rather than to the semantics
>>>>> itself. The actual interpretation structures it describes are
>>>>> mathematically identical.
>>>>> 
>>>>>> It appears to me that the WG has easily accepted such a need
>>>>>> as a fact, but, as I have pointed out in my longish earlier
>>>>>> mail, all evidence known to me goes right against such a
>>>>>> need.
>>>>>> 
>>>>>> Datatype maps in their current form have been in use so long
>>>>>> and so widely and examined with such intense, including by
>>>>>> myself, and without any indication for problems ever raised,
>>>>>> that the only thing I can say about it is that the original
>>>>>> datatype semantics in their precise form have to be
>>>>>> considered robust technology by now.
>>>>> 
>>>>> They are not technology at all, robust or otherwise. They are a
>>>>> purely mathematical device used to describe D-interpretations.
>>>>> Any 2013 D-interpretation is a 2004-D-interpretation where the
>>>>> datatype map is defined by the interpretation map. Any
>>>>> 2004-D-interpretation [[which conforms to whatever external
>>>>> specifications define the meanings of the datatype IRIs in D]]
>>>>> is also a 2013-D-interpretation. Any 2004-D-interpretation
>>>>> which does *not* conform in [[this way]] is insane, should
>>>>> never have been allowed as a legal interpretation, violates
>>>>> basic Web assumptions about IRI identification, will be useless
>>>>> for interoperability and will probably have been prohibited in
>>>>> any case by the specification which defines the particular
>>>>> extension of RDF which uses those datatypes.
>>>>> 
>>>>>> The change, as also pointed out by Antoine Zimmermann in his
>>>>>> original discussion of the topic, comes completely out of the
>>>>>> blue now!
>>>>>> 
>>>>>> I mean, if there really was a problem, why hasn't this
>>>>>> problem been brought up during the LCWD or CR phase of the
>>>>>> SPARQL 1.1 spec, which was finalized just in Spring this
>>>>>> year? Has there been any discussion between the two working
>>>>>> groups on this change?
>>>>> 
>>>>> It is not a matter of sufficient importance to require such
>>>>> elaborate discussion. The problem which had been widely noted,
>>>>> as reported by several members of the WG, was that this section
>>>>> of the 2004 Semantics specification was particularly opaque and
>>>>> hard to follow, and that many readers were puzzled as to why
>>>>> datatype IRIs needed such a different and special treatment
>>>>> from other IRIs. (One confusion which was particularly common
>>>>> and problematic was between the datatype map and the L2V
>>>>> mapping of a particular datatype.)
>>>>> 
>>>>>> And if the problem was the issue with the "pathological
>>>>>> mappings" for XSD datatypes
>>>>> 
>>>>> That was not the primary motivation, but it does serve to as
>>>>> further motivation for the change.
>>>>> 
>>>>> Speaking as a Semantics editor, my chief motivation for this
>>>>> change, apart from its simplicity and clarity, is that it
>>>>> introduces into the RDF semantics some slight hint of the
>>>>> reality of how meanings are specified on the Web. A purely
>>>>> mathematical - model-theoretic - semantics cannot by itself
>>>>> recognize the reality of how IRI meanings are imposed by
>>>>> specifications and used by other specifications. I struggled
>>>>> with how to describe this reality in 2004, and failed, and the
>>>>> simplistic but clumsy idea of a 'datatype map' was invented to
>>>>> patch over the gap that was left.
>>>>> 
>>>>> I sincerely wish that we could incorporate a lot more of Web
>>>>> reality into the RDF formal semantics, but of course to do so
>>>>> now would ruffle so many traditionalist feathers that it is
>>>>> probably impossible.
>>>>> 
>>>>>> , then I have given a solution above, without the need for
>>>>>> replacing the original notion of a datatype map. And again:
>>>>>> the proposed change would by no means remove that problem, as
>>>>>> I will always be able to fool around with datatypes, if only
>>>>>> I have enough semantic power, as with owl:sameAs.
>>>>>> 
>>>>>> I say that the original datatype maps were perfectly ok,
>>>>>> clear and simple enough, at least for me and for several
>>>>>> other WGs, and for several textbook writers, and for several
>>>>>> university lecturers, and so on.
>>>>> 
>>>>> But not for a large number of potential RDF users and
>>>>> developers. Not, in particular, for an entire community of
>>>>> 'linked data' enthusiasts who wish to use RDF in the wider
>>>>> world.
>>>>> 
>>>>>> The change does not solve any existing problem (including the
>>>>>> one discussed above), so why should there be a change at
>>>>>> all?
>>>>> 
>>>>> 
>>>>> RDF is widely perceived as so complicated and arcane that it
>>>>> cannot be practically used; this negative reputation is so
>>>>> widespread that at least one new SW specification was
>>>>> deliberately drafted so as to not even mention RDF. There is a
>>>>> real issue here that we ignore at our peril, and it has been a
>>>>> constant background motivation for the WG discussions. Perhaps
>>>>> this debate you and I are having over this tiny simplification
>>>>> (I will not even honor it with the title of "change" since no
>>>>> interpretation structures or entailments are changed) can be
>>>>> put into some perspective by the observation that the WG did at
>>>>> one point seriously consider removing the nomative semantics of
>>>>> RDF altogether, and may have done so if our charter had not
>>>>> prohibited it. Now that *would* have been a real change.
>>>>> 
>>>>> Pat
>>>>> 
>>>>>> So no problems, so no need for a change, so no need to
>>>>>> discuss the change by other WGs, so no danger of
>>>>>> interoperability issues, spec wars, or whatever (and, on a
>>>>>> personal note, no tons of mails in the following years by
>>>>>> people wanting to know from /me/ how this new formalization
>>>>>> relates to the good old datatype maps they were accustomed to
>>>>>> :-]).
>>>>>> 
>>>>>> So, please, just don't do anything about the original
>>>>>> definition of datatype maps, because there is absolutely no
>>>>>> need to change anything, because there's nothing wrong with
>>>>>> them - that's all I am wishing for Christmas! :-)
>>>>>> 
>>>>>>> Best, Richard
>>>>>> 
>>>>>> Cheers, Michael
>>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------
>>>>> IHMC                                     (850)434 8903 home 40
>>>>> South Alcaniz St.            (850)202 4416   office Pensacola
>>>>> (850)202 4440   fax FL 32502
>>>>> (850)291 0667   mobile (preferred) phayes@ihmc.us
>>>>> http://www.ihmc.us/users/phayes
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> -- Antoine Zimmermann ISCOD / LSTI - Institut Henri Fayol École
>>> Nationale Supérieure des Mines de Saint-Étienne 158 cours Fauriel
>>> 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03
>>> Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/
>>> 
>> 
>> 
>> ---- Ivan Herman, W3C Digital Publishing Activity Lead Home:
>> http://www.w3.org/People/Ivan/ mobile: +31-641044153 GPG: 0x343F1A3D
>> FOAF: http://www.ivan-herman.net/foaf
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 66 03
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
> 


----
Ivan Herman, W3C 
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
FOAF: http://www.ivan-herman.net/foaf