Re: rel=type or rel=profile

On 15 Jan 2014, at 10:43, Henry Story <henry.story@bblfish.net> wrote:

> Hi,
> 
> The request to change from rel=type to rel=profile should really
> be a new issue. Could the person asking for this open a new one,
> then we can gather the arguments for it and I can respond to them
> ( or agree with them of course ).

Ah sorry, it does have an issue. Issue-92.

The Issue says:

"Indeed, until we closed action-122 the spec even said these were notionally equivalent. "

I am not sure why that was removed if it was. The resolution was that "for an LDPC the link header is 
type=LDPC". There are many reasons to put this in the header:

 • the client does not need to read through the whole document to find out if the resource is an LDPC/LDPR
  (similarly if the client sends the header in a POST this allows the server not to have to read the whole body before
   deciding if the resource is of one form or the other )
 • a reason to place this in the header is that it is the server making a statement about the
  resource, and so this is best placed in the metadata ( the space where the server makes statements 
  about the content ). If we think of it that way, then it makes sense that if a server makes a statement
  about a resource being an LDPC then this outweighs statements made in the document.
 
None of this requires one to come to the conclusion that the set of things that are LDPCs are not resources 
for which particular interaction models are defined. The whole LDP spec descriptes these LDP Resources and their 
interaction models.

Some of the arguments during the conversations where that a type does not define an interaction model.
It may not necessarily, but it often does. An rdfs:Class is just a set of things whose extension can
be defined in any number of ways. In our case we can and have defined the ldp:Containers by its interaction
model.

  Furthermore imagine that we decide on some relation between all LDPCs and the ldp:Container type. 
I agree that it is quite possible to have relations betwen things and types that are not the
rdf:type relation: such as isNotOfType, isABorderCaseOf, ... So we could invent another relation,
which we can call ldp:interactionRelation . OWL restrictions show us that for any such relation we can
create a new type

ldp:ContainerInteractionType a owl:Class;
    owl:equivalentClass [ a owl:Restriction;
                  owl:hasValue ldp:Container;
                  owl:onProperty ldp:interactionRelation ] .

In SPARQL this would amount to something like the following
rule

CONSTRUCT { ?ldpr a ldp:ContainerInteractionType }
WHERE {
  ?ldpr ldp:interactionRelation ldp:Container .
}

so the ldp:ContainerInteractionType class is defined as the class ( think of mathematical Sets )
of objects which have the ldp:interactionRelation to the ldp:Container class.

Now my question is: why would ldp:ContainerInteractionType not just be the ldp:Container class?
And if it were not, then you'd still end up with a class, namely ldp:ContainerInteractionType, which would
be the class of all things that had ldp:Container Interactions. So that the relation of an individual
to a class can define its interactions. QED. 
              
Furthermore  one has to understand that statements on the web can be false.
For example in Example 5 of our current spec we have the </netWorth/nw1/> resource
make a statement about two LDPCs <assetContainer/> and <liabilityContainer/> , and
that these are LDPCs. Say someone deletes those two, and that there is a bug in the system,
or a delay somehow. Then the </netWorth/nw1/> could be describing those resources as LDPCs
falsely. Well that's just one type of bug: a false description of the world.


There are a number of further arguments I could make, but I think this will do for the moment.


hope that helps,



	Henry


> 
> Henry
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 15 January 2014 11:34:30 UTC