Re: Comments on POWDER semantics last call document

Dear Peter,

first of all, thank you for the time and effort you have put in
reading the formal document and for your helpful comments.

Please note that I have taken the liberty of slightly re-ordering a
few paragraphs of your original email, in situations where this
helped avoid unnecessary repetitions of text in the answer.

> I take POWDER to be a way of associating (arbitrary) attributed
> information with (groups of) web-accessible resources.  What does this
> need over base RDF (or OWL)? 
> 1/ It needs some way of mentioning and grouping web-accessible
>   resources. 
> 2/ It needs some theory of attribution, i.e., what kinds of entities can
>   provide information and what are their characteristics? 
> 3/ It may need some theory of the kinds of information that can be
>   placed on these resources. 
> 4/ It needs some way of accessing the information, at least accessible
>   from the resources themselves, but, in addition, a way of accessing the
>   information directly from servers for the resources without having to
>   access the resources would be useful. 
> 
> I don't see any of this necessarily "in tension" with the core semantics
> of RDF and OWL.  The last is simply outside the scope of RDF and OWL, as
> it involves issues related to the workings of the web, not representing
> information on the web.  The second and third obviously are the kind of
> thing that RDF and OWL are concerned with (although, of course, POWDER
> might need more expressive power than is available in RDF or even OWL).

In fact I see two points where expressing POWDER in RDF and OWL is a
bit less straightforward than what we had hoped for. The first is your
1st point, which we shall revisit further down this email. We are in
agreement that requirement #3 is exactly the kind of thing RDF and OWL
are for and that requirement 4 is irrelevent to any theoretical
discussion about how to express POWDER in OWL and RDF.

The second requirement sounds like an easy fit when POWDER is described as
an "associassion of attributed information with web-accessible resources".
But this is a slight simplification, as POWDER attributions refer to 
the association itself and not to the descriptors that resources are
associated with. To make this more excpicit, POWDER would ideally reify
the subsumption relation between IRI-defined sets of resources and
descriptor-defined sets of resources, and then link the subsumption
relation itself with the FOAF or DC entity that is asserting the
relation. This is clearly something that, although expressible in RDF,
this group was strongly advised against, for all the well-known theoretic
and pragmatic reasons.

In order to reconcile this, one might well call it tension, POWDER has
been restricted to attributing complete documents as opposed to
individual assertions; effectively, each POWDER document contains an
"atomic" annotation action with a single annotator, validity period,
etc.


> There is no notion of "null" subject in OWL.

That is indeed so. Thank you for the correction, that passage will be
appropriately rephrased in the next draft.

> Instead the document
> appears to be referring to rdf:about="", which may or may not turn into
> a node with the URI of the current document.  (Consider what happens if
> there is an xml:base element in scope.)

That is a known issue, that I can see no way around; please do let us
know if you can think of some alternative. We could mention the
possible caveat (while also referring the reader to [1]). Do you feel
that adding such a warning would improve the document?

> In any case, Example 2-1
> certainly does not show the attribution element being transformed into
> an owl:OntologyProperty.  This section of the document needs to be fixed. 

A left-over from a previous draft, prior to a comment by Ivan Herman
about naming RDF graphs vs. naming OWL ontologies [2]. Thank you for
spotting it, will be changed to what you get if you follow the [RDF/XML]
link in the same example [3].


> The mentioning and grouping of web-accessible resources is where the
> most potential problems arise.  Perhaps surprisingly, RDF and OWL do not
> make much of a connection between certain kinds of URI references (their
> names) and web resources.  To RDF (and thus to OWL) the name (URI)
> http://example.com/ is just the name of some resource, that may or may
> not have any connection to whatever document can be obtained by
> accessing that URI using web conventions.  Users of RDF are thus in some
> sense free to use the name http://example.com/ for any purpose
> whatsoever.  POWDER authors may have to take care not to combine POWDER
> documents with RDF documents that do not use RDF names in the way
> intended by the POWDER specification.
> 
> Further, RDF and OWL do not have any mechanism for grouping names by
> their form.  To RDF (and OWL), there is no closer connection between
> http://example.com/p1 and http://example.com/p2 than there is
> between http://example.com/p1 and mailto:pfps@lucent.com.  POWDER
> definitely has to go beyond the RDF and OWL world view to make these
> connections.
> 
> The transformational approach used in POWDER, going from POWDER to
> POWDER-BASE to POWDER-S, is also not necessarily "in tension" with the
> core semantics of RDF and OWL, even if some tokens are given special or
> exceptional treatment and even if missing information is filled in with
> default values.  In particular, the treatment in Example 3-8 is
> *precisely* in accord with the RDF and OWL view.  

Coming from you, this is a great compliment indeed. Thank you.


> The major problem in the document is a use-mention conflation.  The
> resource referred to by http://example.com/ (which might perhaps be the
> document available at http://example.com/) is (almost certainly) very
> different from the URI http://example.com/ (which is definitely *not*
> the document available at http://example.com/).  The first is referred
> to in RDF by using the URI in a triple as in <http://example.com/>
> rdf:type wdrs:WebDocument the second is referred to in RDF by using a
> literal as the object (only) of a triple as in < http://example.com/>
> wdrs:address "http://example.com/"^^xsd:anyURI
> 
> So what is the problem in the POWDER document?  Well the first way of
> referring to sets of web-accessible documents, in Section 4.3, uses
> wdrs:matchesregex, which is defined as an owl:DatatypeProperty, with
> domain rdfs:Resource.  However, <x,y> is in the extension of
> wdrs:matchesregex only if x is a URI (essentially a string) that matches
> a regular expression.  This means that POWDER is identifying
> web-accessible documents with literal URIs a use-mention conflation.

The issue here is, as you very correctly point out later in your
email, that:

> [...] the value space of xsd:anyURI consists of strings, and the
> lexical mapping is the identity mapping, so the use of I for anyURI
> lexical values is unnecessary.  Note also that using literals as
> subjects of OWL properties is only possible in OWL Full.

Indeed. It seems to me that the error in the POWDER document is that
it fails to explicitly map the "xxx"^xsd:string literal that gets matched
against the regexp to the "xxx"^rdf:XMLLiteral that can be interpreted
into an abstract resource ( I = IS for rdf:XMLLiteral, [7, Sect 1.4] ).

In [8, Section 5.1] I read that:

  RDF applications may use additional equivalence relations, such as
  that which relates an xsd:string with an rdf:XMLLiteral
  corresponding to a single text node of the same string.

which should do the trick. We can know say that:

  We extend RDF with a datatype property wdrs:matchesregex as shown
  below:

  wdrs:matchesregexp rdf:type owl:DatatypeProperty .
  wdrs:matchesregexp rdfs:domain rdfs:Resource .
  wdrs:matchesregexp rdfs:range xsd:string .

  We further stipulate that <x,reg> is in IEXT(I(wdrs:matchesregex))
  if and only if:

    * reg conforms with regular expression syntax, AND
    * there exist sss^xsd:string and uuu^rdf:XMLLiteral such that:
       - <sss,uuu> is in the extension of the equivalence relation
         which relates an xsd:string with an rdf:XMLLiteral
         corresponding to a single text node of the same string, AND
       - sss matches the regular expression reg, AND
       - uuu is in the domain of I, with I(uuu)=x

What do you think?


> It would be much better to have a POWDER class of web-accessible
> resources, each of which has (at least) one URI (that can be used to
> access the resource), as in 
> 
>  Declaration(Class(wdrs:webAccessibleResource))
>  Declaration(DataProperty(wdrs:hasIRI))
>  Range(wdrs:accessibleVia xsd:anyURI)
>  SubClassOf(wdrs:webAccessibleResource
>             MinCardinality(1 wdrs:accessibleVia))
> 
> The "intended" meaning of wdrs:hasIRI is then
> 
>   <x,y> is in the property extension of wdrs:hasIRI IFF
>   x is a resource that can (currently) be accessed via the IRI y 
> 
> This is similar to the treatment in Section 4.6, but it avoids 
> problems there.
> 
> Then the POWDER mapping would end up with subclasses of
> wdrs:webAccessibleResource whose wdrs:accessibleVia values would match
> the regular expressions, using a "special" property, as in:
> 
>  Declaration(DataProperty(wdrs:hasAURIThatMatches))
>  Range(wdrs:hasAURIThatMatches xsd:string)
>  IntersectionOf(wdrs:webAccessibleResource
>                 HasValue(wdrs:hasAURIThatMatches <regexp>))
> 
> The "intended" meaning of wdrs:hasAURIThatMatches would be
> 
>    <x,y> is in the property extension of wdrs:hasAURIThatMatches IFF 
>    x has a value for wdrs:hasIRI that matches the regex y
> 
> This could then be done better using the OWL 2 data range facilities as 
> 
>  IntersectionOf(wdrs:webAccessibleResource
>    SomeValueFrom(wdrs:accessibleVia 
>      DatatypeRestriction(xsd:anyURI pattern <regexp>)))
> 

This approach is, however, restricted to web-accessible resources,
which POWDER is not [6]. POWDER needs to group resources by the form
of their IRIs, their names, regardelss of what (if anything at all)
these names resolve to.

As to using OWL 2 to do the pattern matching bit, we are in absolute
agreement that this is a better way of doing this, which is why
the informative Section 4.6 was included. We could, however, not make
Section 4.6 normative and remove Section 4.3, as OWL 2 is not stable
yet.


> There appears to be some confusion in the document as to names of
> built-in properties, particularly wdrs:matchesregex[p]

Ooops. Will be fixed in the next draft, thanks.

> I would not say "semantics" so much in the document.  The document is
> mostly specifing a transformation.  It is true that this then defines
> the meaning of POWDER documents.  However, saying "transform" does not
> give the impression that the transform *is* the semantics. 

We do not see 100% eye-to-eye on this one, as I think of the document
as specifying the *result* of the transform, as opposed to a
transform. Although it is true that the document is written with an
XSLT tarnsform in the back of our heads, there is no specific XSLT
rules appearing anywhere, neither is there anything in the expected
outcome of the transform that is specific to XSLT (please correct me
if I am wrong here, but I don't see why one couldn't, or, indeed,
wouldn't, achieve the same result using, for example, AWK).

In this sense, the document is about the semantics itself of
POWDER/XML documents, as opposed to being about a transform that
allows one to retrieve the semantics of said documents.


> There is no formal notion of an RDF statement being about anything. RDF
> statements have subjects, predicates, and objects. 

Indeed, thank you for the correction. I assume that you are referring
to the second paragraph of Section 2.2, which will be rephrased
accordingly. Have you spotted any other instances of this mistake?


> I am not sure what force the "SHOULD" in the issuedby section has.  RDF
> is not prescriptive, so using a node as the object of a statement with
> issuedby as predicate *enforces* that the object is in the range of the
> property. 

Please note that the range of <issuedby> is marked as a "Feature at
Risk" in the current draft. The specifics of various possible values
of the <issuedby> element in POWDER/XML documents (and the
corresponding RDF triples in POWDER-S documents) are still being
discussed by the group. A definite resolution will soon be reached,
which will be reflected in a more rigorous phrasing for this passage.


> Using a verbose syntax for OWL makes it hard to grasp the meaning of the
> transform.  I think that it would be better to use TURTLE (and even
> better to use the OWL 2 functional syntax or even an informal syntax
> like the Manchester syntax). 
> 
> Note that the namespace associated with the ox prefix is still under
> discussion in the OWL WG.   

RDF/XML was chosen as it is expected that one of the typical POWDER
use cases will be to generate RDF/XML from POWDER/XML and then use
tools such as Jena to draw inferences over the resulting graph. With
this scenario in mind, providing the RDF/XML equivalents of the
various POWDER/XML constructs is seen as a way of helping prospective
POWDER developers test their tools.

Although an argument can be made that machine-readable test cases are
a different issue than presentation in a human-readable document, a
great amount of man-power has been saved by having RDF/XML examples
embedded in all our documents, as these examples formed the nucleus
around which the test suite was constructed. This was no minor savings
for a small group like POWDER, with very limited resources.

The group shall consider replacing all RDF/XML examples with a more
concise notation, now that POWDER syntax and semantics are getting
close to being finalized; an one-off conversion will be more
manageable and less error-prone than consistently maintaining two
notation variations throughout an actively evolving document, such
as the POWDER-formal document up to now.


> I would suggest using TURTLE as an example of another serialization of
> RDF graphs instead of N3. 

Thank you for pointing the possibility out, it shall be considered if
there are enough instances where the ; and , short-hands can be applied.


> The use of triple syntax requires some sort of pointer to an appropriate
> definition.

A fair point. A reference to the definition of the notation will be
provided in the next draft.


> Why not use XML Schema datatypes more in the transformation to RDF?

Can you offer a specific instance where this would make the text
and/or the examples clearer or more accurate?


> There may be a use-mention problem for certifiedby and supportedby.  If
> these properties are supposed to have URIs as ranges, then rdf:resource
> is not the correct kind of thing to use. 

That is correct, thank you. Will be fixed in the next draft.


> I think that it would be a good idea to provide domains and ranges for
> the POWDER properties, e.g., something like wdrs:IRISet for
> wdrs:matchesregex.

But we do so. For wdrs:validfrom, wdrs:validuntil, wrs:certifiedby,
wdrs:supportedby and wdrs:issuedby cf. Sect. 2.2; for
wdrs:matchesregexp cf. Sect. 4.3.

We note the editorial comment for Sect. 2.2, that we could show
explicit rdf:range triple instead of mentioning the range in the text.
Or have I misunderstood your comment and you meant something else?


> I further think that there should be some sort of
> true semantics document that talks about the extensions to RDF that are
> used in POWDER. This document would look something like the RDF
> Semantics document or the OWL Semantics and Abstract Syntax document (or
> its replacement in OWL 2).

Section 4.3 is serving this purpose. We feel that, nowithstanding its
unquestionable importance, the *size* of the formal definition of the
extension is not such that it justifies a full-blown document.


> There is no built-in OWL resource with name owl:Property.  Triples using
> it should probably be removed.

Thank you for spotting this, this is both wrong (should read
rdf:Property) and gratuitous in the presence of owl:DatatypeProperty
immediately above. Will be fixed in the next draft.


Thanking you for you efforts,
Stasinos



[1] http://www.w3.org/TR/2004/REC-owl-guide-20040210/#OntologyHeaders
[2] http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0053.html
[3] http://www.w3.org/TR/2008/WD-powder-formal-20080815/example_2_1.rdf
[4] http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0046.html
[5] http://lists.w3.org/Archives/Public/public-powderwg/2008Jul/0031.html
[6] http://www.w3.org/TR/2008/WD-powder-grouping-20080815/#isan
[7] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
[8] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/

Received on Saturday, 13 September 2008 07:19:34 UTC