TagIssue57Proposal27/Earlier

JAR July 2012, content moved away from TagIssue57Proposal27

This proposal combines elements of TagIssue57Proposal26 (parallel properties) and HR14aCompromise (do what you like but keep your hands off of sameAs).

Goals of this exposition:

• Start with first principles, not historical accident
• Do not assume the webarch party line or world view
• Say something general about architecture, not specific to RDF or URIs
• Explain why the problem seems to be peculiar to RDF

Background

See TagIssue57Proposal27/Background

Distinctions can be made at the "statement" or "command" level.

Besides these four approaches, when the incompatibility seems to have to do with the meaning of identifiers, there is another way to distinguish which meaning applies. We can do it at the level of syntactic constructs that contain a contested identifier as a part - what one might call "operator applications" C[U] of which U is an identifier that is a direct part (operand) of the construct. ("Operator application" is meant generically: a statement, command, method call, element, attribute, etc.) To make the distinction, we replace an application C[U] containing a contested identifier U with an operator application S1 where extension 1 is meant, or with S2 where extension 2 is meant.

Since the identifier is fixed (that's the whole problem), we don't have S1 = C[U1] and S2 = C[U2], but rather S1 = C1[U] and S2 = C2[U]. We change something that's not the operand-position identifier.

Note: we only have to do this when the meaning of U is contested. Applications C[V] where V is uncontested can be left alone.

• Of course in RDF identifiers are URIs, but the approach is general.

A way out

It is operator-application semantics, not identifier semantics, that matters.

So here is the key hypothesis. What matters, it is supposed, to parties preferring particular extensions to identifier meaning, is that their meaning be expressible using some construct that has their choice of identifier as a part; not that the identifier "identifies" anything in particular. The identifier meaning extension was created as a means to an end, and the end is (a) to have something that has the desired meaning, and (b) for that identifier to be used in that something. As long as S1 and S2 (expressing the distinct meanings) are in terms of U, i.e. S1 = C1[U] and S2 = C2[U] for some C1 and C2, and have the desired meanings, it doesn't matter what U "identifies".

Factor apparently incompatible extensions through projections.

Based on this hypothesis we introduce a new identifier meaning extension (call it extension 3) giving "overloaded" meanings (this will be explained). Write the overloaded meaning of U (at the meta-level) as meaning3(U). By fiat (or by construction), meaning3 will have the the property that there exist functions (call them "projection" functions) p1 and p2 satisfying p1(meaning3(U)) = meaning1(U) and p2(meaning3(U)) = meaning1(U), i.e. meaning1 = p1 o meaning3 and p2 p2 o meaning3.

(In fact this is all we need to assume about meaning3.)

It may be possible to arrange for syntactic constructs P1[] and P2[] expressing p1(-) and p2(-). We would then write S1 = C[P1[U]] and S2 = C[P2[U]], i.e. C1[] = C[P1[]] and C2[] = C[P2[]].

Replace the original operator with operators specific to each extension.

Writing P1[] and P2[] may be clumsy or even impossible in a given language. But we can usually introduce C1[] and C2[] as shorter ways to express c(p1(-)) and c(p2(-)), i.e. meaning(C1) = c o p1 and meaning(C2) = c o p2. Thus S1 = C1[U] and S2 = C2[U].

• e.g. in RDF, writing P1[U] would require use of a blank node, while C1 and C2 could just be new classes or properties.

When defining C1 or C2, it will suffice to say that its meaning is the composition of c (the meaning of C[]) with p1 or p2.

• in RDF we might do this with an annotation on the property, e.g. C1 extension-1-related-to C means that the meaning of C is the composition of the meaning of C with p1.

It doesn't matter what identifiers mean as long as the projections exist and work properly.

Under this plan, what an identifier means doesn't matter as long as there exist functions p1 and p2 that allow the recovery of meanings 1 and 2 from their "overloaded meaning".

In particular, if there exists a function p1 that maps meanings under extension 1 to meanings under extension 2, then we can take meaning3(U) = meaning1(U), and p1 = identity; and the overall arrangement will be parsimonious for those using extension 1.

This condition is satisfied as long as extension 1 doesn't introduce any aliasing relationships (equations) between identifiers that don't also hold for extension 2 (and, in general, all other extensions).

• In RDF, this means users of an extension who are interested in interoperability shouldn't write U owl:sameAs U', which, otherwise, they might be tempted to do if meaning(U) = meaning(U') under the extension.

How this might play out in RDF

Contested vs. uncontested URIs

Whether the meaning of a URI is contested or not depends on the context in which it occurs, especially media type. For example, we don't for the most part find incompatible extensions of URI meaning in HTML (at least not yet), but we do in RDF. There is nothing special about RDF regarding the above analysis; it just happens to be the outstanding present-day example of a language in which incompatible extensions of URI meaning are an issue.

Hash URI meaning is (relatively) uncontested in RDF; and in practice, it has turned out that hashless http: and https: URIs for which one doesn't get 2xx responses also have generally uncontested meaning in RDF, in spite of the absence of any governing specification, although some ambiguity remains in this case (especially regarding one's attitudes toward time and authority). The contested URIs include many, if not all, hashless https: and http: URIs for which one gets 2xx responses. (Some 2xx URIs are uncontested in the sense that their meaning happens to coincide under the various extensions: specifically, those for which retrieved representations seem to say that the URI refers to the generic resource whose representations are retrieved using the URI.)

Other kinds of URIs are not used much in RDF, except perhaps urn:lsid: in certain communities, so they can probably be considered uncontested.

(URIs occurring in property position, or as the object of an rdf:type statement, must be predicates, so maybe we can arrange for these occurrences to sidestep the issue. In any case it feels like the problem is less severe in predicate positions.)

The adoption of the present proposal converts contested and uncontested URIs into overloaded and nonoverloaded URIs.

There are two dominant extensions, one of the "generic resource" variety (a URI refers to a generic resource whose representations are retrieved using the URI) and the "take at face value" extension (to find out what a URI identifies, read a representation retrieved using it; the representation will answer the question). But is easy to imagine others - for example, it is not obvious that the "generic resource" theory is the best match to the way URIs work in HTML a@href, to their use in identifying RDF graphs, or to their use as XML namespace identifiers; and in the future some new community might want interoperability involving these other situations.

Parallel data properties

Consider first the easier case, that of data properties (those whose ranges include only RDF literal values). Suppose we want to express meanings of the form prop(meaning1(U), x) for various overloaded URIs U, where prop is some datatype property. We define a property URI :Prop1 whose meaning is prop o p1, and write

<U> :Prop1 x. 

We have two ways to say that :Prop1 has the meaning prop o p1. One is to define a second URI, say :UrProp, as a name for prop, and write

:Prop1 :Xyz1 :UrProp.

to relate the two properties. Here :Xyz1 denotes a second-order inverse functional property, which would be defined as part of this proposal, that relates a property (on the right) to p1 composed with that property (on the left). (TBD: figure out what to call :Xyz1. HT: I think earlier we were calling the SubjLiteral or DocLiteral (depending on the extension).)

The meaning of &ltV> :UrProp x where V is nonoverloaded would be clear.

The other way would be just to leave :UrProp unnamed, i.e.

:Prop1 :Xyz1 [].

in which case of course the intended application-level semantics of :Prop1 would need to be described in the documentation for :Prop1 (as opposed to being inherited from the documentation of :UrProp).

Now, whenever one sees

<U> :Prop1 x.

one can infer that there exists a y such that y = p1(meaning3(U)) and y is prop-related to x:

<U> :Proj1 [:UrProp x].

where, again, :Proj1, which denotes p1, would be defined as part of the proposal.

This is called "parallel properties" because in a diagram :Prop might be parallel to :UrProp (although in this simplified case they seem to intersect at x).

It is very important that the projections are functions. This enables "smushing" i.e. the ability to postulate a single object y simultaneously having many properties inferred from statements <U> :Prop1 x, <U> :Qrop1 w, <U> :Rrop1 v, and so on.

One meta-property :Xyzi is needed for each extension. Each extension could have in principle have its own property parallel to :UrProp, although this seems unlikely in practice.

OWL-DL doesn't support second order properties, so the relationship of :Prop1 to :UrProp (expressed using :Xyz1 above) would have to be expressed differently in OWL-DL, using a property chain axiom. (TBD)

Important: There is no a priori reason to suppose that the domain of the projections p1 and p2 is not the entire type rdf:Resource; nor is there any reason to suppose otherwise. Similarly for the ranges of p1 and p2, which furthermore do not need to be distinct from one another. But we'll take up the question of whether some amount of exclusion would be useful below.

Parallel object properties

This approach generalizes to the case of object properties; we again need one :Xyzi meta-property per extension. This time :Prop1 involves not just the projection p1 but its inverse as well. (TBD: diagram)

The fact that object properties have two "operands" raises the possibility that different extensions might be involved in different operand positions (i.e. subject vs. object of the statement). If there are N extensions this would require N-squared second-order properties (N cases for the subject position and N cases for the object position) in order to sort out the various cases. (For RDF as currently used we ought to be able to get away with N=2, the extensions being generic resources and face-value). (TBD: diagram)

Monotonicity

In simple situations, at least, this approach should support the goal of monotonicity, i.e. achieving a graceful migration path from non-interoperating RDF to interoperating RDF.

People writing RDF and defining ontologies can start out assuming the extension of their choice, without annotating predicates, and everything will "just work" (TBD: explain and justify this claim). They can interpret (subject to some modest restrictions) their URIs as not overloaded, but rather as having semantics given by their favorite extension.

Later, should interoperability via overloading become important to them, they can add :Xyzi annotations to their properties to document which extension they were assuming.

The only constraint needed to make the transition from a particular incompatible extension to overloading semantics work is to avoid depending on equations (owl:sameAs) that derive from assuming that some particular extension is in effect. One can still write owl:sameAs where interoperability is not a goal, but if these equations are scoped to noninteroperating partitions, and inessential in interoperation scenarios, then projections onto other extensions will still work.

(There may be additional restrictions to observe regarding combination with uncontested URIs; I'm unable to sort out this situation clearly, but see below.)

Issue: Some projections are partial

Some projections won't have well-defined results for certain URIs, based on the natural rule defining the projection. For example, for poorly behaved (e.g. highly variable) 2xx URIs, it may be impossible to discern what the associated "generic resource" is. Or, for URIs from which no representation is retrieved that don't say what the URI means (contain no statements to the effect of "&ltU> has such and such a property" or "what U identifies is ..."), the "take at face value" rule doesn't specify a result.

Exactly what happens in these cases would be up to the definition of the particular projection function. Two possibilities: (1) there is fallback to some other semantics, such as another projection function; e.g. perhaps "face value" could fall back to either "generic resource" or "primary topic"; (2) the overloaded denotation may just fail to map under the projection, in which case a statement involving such a parallel property would just be false.

Issue: interoperation with nonverloaded URIs

If prop has a URI, say :UrProp, and V is a nonoverloaded URI, one could just write

<V> :UrProp x.

to express prop(meaning(V), x), and forget about :Prop1, :Prop2, etc. altogether in this situation. However, this is annoying for a couple of reasons.

• A likely error would be using :Prop1 where :UrProp was required, or vice versa. That is, people writing RDF, especially those who don't care about interoperability, may not be able to remember (or accept) that they have to choose the correct property depending on whether the subject URI is overloaded or not.
• This necessitates defining twice as many property URIs as one might like; or else commits one to using any given property URI either with overloaded URIs, or with nonoverloaded ones, exclusively.

We really want :Prop1 to mean prop for nonoverloaded URIs and prop o p1 for overloaded ones. That is, restrict the above inference rule to the situation where U is overloaded, and add a rule allowing to deduce

<V> :UrProp x.

from

<V> :Prop1 x.

when V is not overloaded.

There are a few ways to approach this:

1. The cleanest approach is to accept the consequences and move on.
2. Alternatively, choose between the two rules based on how the subject is written in the RDF statement (using an overloaded URI, vs. a nonoverloaded URI or some other syntax).
3. Or, arrange for the class of denotations of overloaded URIs (that is, the domain of the projection functions) to be disjoint from the class of denotations of nonoverloaded URIs, so that inference based on denotations can tell what kind of URI did the denoting, and thus which inference rule is to apply.
4. Or, somehow take all URIs to be overloaded.

None of these is an obvious winner. The inference rules for number 2 are inexpressible in OWL which, like RDF (but unlike N3), is referentially transparent - i.e. inference rules (axioms) are understood in terms of what URIs denote, independent of how those denotations are denoted. Number 3 puts a peculiar division (overloaded vs. nonoverloaded) at the very upper reaches of any ontology applied to the domain of discourse, but may be workable. Number 4 prevents aliasing in almost all cases, and this would certainly conflict with current RDF and OWL content using noncontested URIs and deployed in good faith.

There is some similarity here to the classification, proposed by some parties who seem to not understand the httpRange-14 rule, of everything into "information resources" and "non-information-resources" (NIRs). While the class NIR has little utility and considerable danger, since uncontested URIs can equally well refer to either IRs or NIRs, in support of #3 :Nonoverloaded membership would enable a useful conclusion (i.e. that <V> :UrProp x). If :Overloaded is by fiat disjoint with generic resource (GR seems to be roughly the same as IR), we will not lose the ability to identify GRs using uncontested URIs, which is essential for processing "legacy" content.

(:Overloaded / GR disjointness is obviously in opposition to the desire of some to institute :Overloaded = information resource = generic resource, but #3 provides a reason for such disjointness that might otherwise be lacking.)

The existence of things that are unnamable using uncontested (e.g. hash) URIs would of course be quite radical.

(TBD: Show how to express case #3 inference rules in OWL-DL, assuming a partition of owl:Thing into classes :Overloaded and :Nonoverloaded. Method A: define every property :Propi as the disjunction of subproperties restricted to the two classes, with a property chain axiom for one but not the other. Method B: define each projection :Proji as the disjunction of two properties, one of which is the restriction of the identity relation on :Nonoverloaded, and the other of which is functional with domain :Overloaded. Easier: since in any case most RDF content is unuseable in OWL-DL without deep cleaning, we should probably impose separate, more severe criteria (#1) when interoperability with OWL-DL is to be anticipated.)

(more work to be done here, hoping for help from HT and JT)

Issue: Deciding whether a URI is to be considered overloaded or not

This seems to require a great deal of judgment, as there are numerous cases:

• Hash URIs and non-http: URIs (nonoverloaded based on syntactic considerations)
• non-2xx hashless http: URIs (general consensus in RDF/linked data community, but maybe not outside)
• 2xx with unrecognized representations (perhaps latent or inaccessible face-value content?)
• 2xx where some or all representations do not say what the URI denotes
• 2xx where some or all representations say the URI denotes the GR
• 2xx where some or all representations where you can't tell if it denotes the GR or not
• etc.

A determinate rule, whose evaluation does not require judgment, for deciding whether a URI is overloaded, would be highly desirable. The simplest and most robust rule would be independent of network contingencies, i.e. just consider all hashless http: URIs to be overloaded. This would probably result in difficulties relating to current deployed use of so-called "303 URIs" which have been used, in good faith, with aliasing. A more compatible criterion would be the one familiar from the httpRange-14 resolution, i.e. a 2xx response signals that the URI is contested / overloaded.

What's going on?

Overloaded URIs denote single things, but those things are peculiar things; they carry within themselves (or uniquely determine) the multiple things that one would get under the various incompatible extensions.

The specification of overloaded meanings in terms of projection functions is called a "product" or "limit" in category theory.

If you want a way to interpret overloaded URIs, you might consider them to denote tuples whose components are all of the possible meanings that the URI would have under the competing extensions. The projection functions select the appropriate component of the tuple.

But this is just one of many interpretations that would be consistent with the constraints.

Another interpretation is to take denotation to be the identity function on overloaded URIs, and the projection functions to be what the denotation function would have been under the corresponding extension.

More generally, denotation of overloaded URIs could be some arbitrary bijection; although perhaps some bijections are more useful than others.

Identity or bijection may be going too far in forbidding URI equivalences. There is an opportunity here to agree (as was urged by one TAG member at the April 2012 TAG face-to-face) that URI equivalences that are consequent to the HTTP specification must hold, even though these are not required under the RDF specification. On the other hand there's nothing in the take-at-face-value extension to prevent unequal but HTTP-equivalent RDF URI references from being treated differently.

Because overloading is a purely formal construction designed to mediate a dispute, the important thing is not what these things "are" ontologically, but how they relate to other things (specifically, the projection functions), and the inference rules that apply in relation to them.