Re: LDP agenda for 20 January - issue-92

On 20 Jan 2014, at 18:13, Arnaud Le Hors <> wrote:

> I expected a few people to be missing but only four of us turned up for the first half hour so the official meeting didn't take place. 
> We used the time as an informal meeting, which a few others joined over time, to discuss some of the remaining issues. 
> No minutes were taken, today's meeting was basically canceled.

I came in late too, just in time to discuss Issue-92 [1] if I can summarise some of 
the arguments. 

1. the backup argument

   The Backup argument made in support of issue 92 does not hold. Issue-92 says:

     By Alexandre's own example (making a backup of an LDPC/LDPR), the backup is just a document (it has the same RDF content, including the same rdf:type(s), but a different interaction model), not an LDPC or LDPR.

  a) telling the truth

  There can be false statements made on the web, and if a document makes a false statement about a resource
  then that is a problem with the document, but since we rely on the final analysis on the headers the
  interactions can be done ok.

  In terms of truth the argument was made here:
  The reliance on the header was voted as resolution of issue-91

  b) How to make backups

  The remaining argument Arnaud had was that this forces the 
  document to lie. If someone wants to make a backup and it is

    <> a ldp:Container .

  then the document is not telling the truth. There are in fact a
 number of answers on how to make backups.

   change the mime type completely ( eg: text/plain ) and specify what 
   the mime type used to be
   put the full text in an archiving format, something that says when
    the information was found, where it came from etc...
   use N3 to do the previous with something like 
     { <> a ldp:Container } arch:meta [ 
               writtenBy <joe>;
               fetched "02-13-2013T00:00:00"^^xsd:dateTime;
               validUntil "02-14-2013T00:00:00"^^xsd:dateTime ] .
   use an blank node for the container
    [] a ldp:Container;
      from "02-13-2013T00:00:00"^^xsd:dateTime;
      to "02-14-2013T00:00:00"^^xsd:dateTime .

  c) archiving argument is in a vicious spiral

  replacing the rdf:type with another relation - say ldp:interaction - would not help.
  Say we agree that it is better to write

  <> ldp:interaction ldp:Container .

  in the body of the document. Then the same problem would come up if one wanted to
  archive that document. Either <> acts like an LDPC or it does not. Luckily the previous
  two points show that the archiving problem is not a problem.

2. rel=profile

the rel=profile spec is currently broken.
I made an argument for that and got support from Sandro Hawke here:

It is broken badly enough that minor tweaks cannot repair it. 
This shows that my -1 was completely justified, and so we are no longer
in a position to be able to assume the group is on a consensus behind
issue-92 with me as the only outcast. 

3. rel=interaction

  If one were to create a new relation say rel=interaction which would
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.
Hope this helps,



Received on Wednesday, 22 January 2014 10:32:04 UTC