Re: [ISSUE-57] Drawback to Parallel Properties

Hi Sean,

You are absolutely right, and I don't think it's such a minor comment.
Should the 'Providing and Discovering' or 'URIs in data' documents ever be
revised, the point should be made.

The reasoning vulnerability may be related to the fact that (as far as
I've heard) the 'URIs in data' proposal has not had much uptake.

Parallel properties was seen as a compromise intended to get
interoperability between the two popular behavior patterns. Like many
compromises, it may end up failing to please anyone.

Parallel properties certainly was on offer (via 'URIs in data') as an
opportunity to do away with the much maligned 303 and 2NN business. TimBL
and Eric Prud'hommeaux turned down the offer, as seen by their recent
effort to push 2NN through the IETF process. Perhaps the rejection was for
reasons similar to what you describe - it's hard to reason correctly about
parallel properties.

A consistency checker (e.g. an OWL reasoner) could detect the problems you
raise, given the right axioms. However, most RDF sources are not too keen
on consistency validation and would happily generate noninteroperable
content even if there were a published specification. We've seen this
situation before, where HTTP servers, with which validation has never been
popular, happily generate noninteroperable HTTP content.

I wonder if this old interoperability discussion is completely over, or if
it's a time bomb that won't be taken seriously until the pain level gets
high enough (the RDF analog of 'browser wars'). Who knows whether that will
ever happen.

Best
Jonathan


On Wed, Oct 29, 2014 at 10:26 AM, Sean B. Palmer <sean@miscoranda.com>
wrote:

> This is a minor comment on a technique described in:
>
> Providing and Discovering URI Documentation
> Editor's Draft 2 February 2012
> http://www.w3.org/2001/tag/awwsw/issue57/20120202/
>
> Section 4.2 describes a method called parallel properties, which has
> been independently invented on several occasions.
>
> The method consists of creating properties that are designed to refer
> to the "designated subject" of a document, which bears some relation
> and may even be equivalent to its foaf:primaryTopic.
>
> To expand such references, we also need to give a name to the
> relationship between the asserted property and the inferred property.
> In the example graph given in the section, these are eq:epicenter and
> "has epicenter". I shall refer to this relation as the "direct
> property".
>
> That is to say, this example from the section:
>
>   <http://example/eq018> eq:magnitude 6.9.
>   <http://example/eq018> eq:epicenter <geo:37.040,-121.877>.
>
> Implies the following:
>
>   <http://example/eq018> pp:designatedSubject [
>     [ is pp:directProperty of eq:magnitude ] 6.9;
>     [ is pp:directProperty of eq:epicenter ] <geo:37.040,-121.877>
>   ].
>
> There is a significant drawback to this method. It is that it appears
> that you can use non-parallel properties on the same subject, whereas
> in fact this leads to inconsistencies. A good example of a common
> non-parallel property that someone may attempt to use is owl:sameAs:
>
>   <http://example/eq018> owl:sameAs
>     <http://example2/document.rdf#eq018> .
>
> This statement would cause all sorts of inferential chaos. In the
> earthquake example such incorrect inferences may not be regarded as
> especially harmful, but there are alternative scenarios in which they
> would be, such as where a document has another document as its
> designated subject. In that case, the inferential chaos caused by
> owl:sameAs would make the metadata of both documents
> indistinguishable.
>
> To recap, the properties eq:magnitude and eq:epicenter in the example
> appear to have the nature of non-parallel properties, and would cause
> confusion unless specifically documented as a pp:ParallelProperty
> instances, with the characteristics of parallel properties being
> widely known. This problem is similar to spoofing. There is no
> requirement preventing it in the list of desiderata (Section 1.1).
>
> Note that parallel property analogues to non-parallel properties can
> be made. In the case of owl:sameAs, for example, we could say:
>
>   { ?s pp:designatedSubjectSameAs ?o } =>
>     { ?s pp:designatedSubject [ owl:sameAs ?o ] } .
>
> And also:
>
>   { ?s pp:sameDesignatedSubjectAs ?o } =>
>     { ?s pp:designatedSubject
>         [ owl:sameAs [ is pp:designatedSubject of ?o ] ] }.
>
> But this approach is not very straightforward.
>
> --
> Sean B. Palmer, http://inamidst.com/sbp/
>
>