Re: LDP agenda for 20 January - issue-92

> 3. rel=interaction
> have an equivalent in rdf - call it ldp:interaction - then if is defined
> in such a way that the following is true
> 
> ldp:Container  a owl:Class;
>    owl:equivalentClass [ a owl:Restriction;
>                  owl:hasValue ldp:Container;
>                  owl:onProperty ldp:interaction ] .
> 
> then I can't object to it. But I'd just point out that 
> 
>   a) this requires a good definition of ldp:interaction and 
rel=interaction
>     ( we can't write a blank cheque in advance of seeing what the text 
for 
>     such a relation is going to be ). 
> 
>   b) it really is not clear what is gained by this, since there is an
>     equivalence between ldp:Container and ldp:interaction as shown above
>     and so rel=type would work as well.

The major point of disconnect is that not everyone agrees with you that 
part of the information conveyed by rel=type or rdf:type is/includes "the 
interaction model".  In more familiar terms, some believe that data model 
!= object model; when you assert that rdf:type == object model, not 
everyone is convinced of that.  I know Arnaud has tried to render that 
explicit several times.  At times it has sounded like you understood such 
a distinction, at others it did not.

I.e. this really devolves to: what does it *mean* for 'X to be "of type" 
Y' ?  What conditions/assertions does that equate to, what is 
inside/outside of that statement.

It's not obvious that the "good definition" you'd want for rel=interaction 
exists for rel=type or rdf:type.  I consulted the Book of Armaments [1] 
for rdf:type, finding just this: "rdf:type is an instance of rdf:Property 
that is used to state that a resource is an instance of a class." 
Arm-chair exegesis of that seems inconclusive with respect to the question 
of data vs object type (whether 'class' includes any part or all of 
interaction model automatically, or if that is left open for the class 
definition to say).  If we conclude that [1] just leaves it open, then 
it's up to the definition of the class to lay that out.  We are defining 
ldp:Container, so that would put it in our lap. 

rel=type is defined at [2], which says:    The "type" link relation can be 
used to indicate that the context resource is an instance of the resource 
identified by the target Internationalized Resource Identifier (IRI).
As I related earlier, I discussed the author's intent with the author, and 
that intent was "basically" to be like rdf:type.
As Erik told us yesterday, often the RFC language is open to 
interpretation, and many (not all) in RESTy space believe that all 
interactions have some context with them (making open language 
unsurprising).  It's a different set of assumptions from RDF's; that 
simple.

If we accept that there are, today, varying interpretations of what 'X is 
"of type" Y' means to members of the working group, and we have no 
external normative reference that resolves it, then we have a few options:
1: keep things as is.  we can still use rel=type ldp:Container, and leave 
the interpretation of that to the base specs.  given current evidence, it 
will not be particularly useful for interop based on a detailed 
understanding of its meaning (in the data vs object model sense).  that 
might be Good Enough.  LDP can still say where it is required/etc., e.g. 
on post-to-create.
2: define what we mean (the "good definition", i.e. spell out whether 
"being" an ldp:Container is just about what EricP called 'structure', or 
it is about structure *and* interaction).  I see little hope for a 
consensus on either, given what the WG has said to date (if we cannot even 
agree on How Many concepts there are, game over).  Once we have a "good 
definition"(s), choosing the syntax we can agree on will be IMO trivial. 
Nb: If we could agree on "how many", we might have 2 definitions to make 
"good".

Herewith, I propose we close issue 92 with option 1 above, i.e. a 
disposition of "no change".
If we cannot get consensus on that, then we are deadlocked and there's a 
process for that.


[1] http://www.w3.org/TR/rdf-schema/#ch_type
[2] http://tools.ietf.org/html/rfc6903#section-6

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario