Re: [oslc-core] Review comments on Attachments 3.0 draft

[Ian Green1 <ian.green@uk.ibm.com>]

Thanks Sam. Comments continue below.

best wishes,
    -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational

<oslc-core@lists.oasis-open.org> wrote on 16/01/2015
17:02:23:

> From: Samuel Padgett <spadgett@us.ibm.com>
> To: Ian Green1/UK/IBM@IBMGB
> Cc: Arnaud Le Hors <lehors@us.ibm.com>,
"OASIS OSLC Core TC 
> Discussion List" <oslc-core@lists.oasis-open.org>, Steve
K Speicher 
> <sspeiche@us.ibm.com>
> Date: 16/01/2015 17:02
> Subject: Re: [oslc-core] Review comments on Attachments
3.0 draft
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> Thanks, Ian. I'll make the accepted changes. Here are my comments
on the
> other items.
> 
> Ian Green1 <ian.green@uk.ibm.com> wrote on 01/16/2015 05:06:55
AM:
> 
> > Thanks Sam.  I've created a review register at https://wiki.oasis-
> > open.org/oslc-core/Attachment30Review.   I will keep this
up to date
> > as issues are closed etc.  Suggest we keep the discussion
to the 
> mailing list?
> 
> Sure.
> 
> > > Even application/rdf+xml can be treated as an LDP-NR if
created with the
> > > appropriate interaction model when creating the attachment.
This is done
> > > with the HTTP Link header (as defined in LDP). So I think
we're covered.
> >
> > I don't see this when I read the LDP spec (4.4.1.2).  Where
should I
> > look?  4.4.1.2 describes that a server MAY indicate in Link
header
> > that an "exposed" resource is non-RDF. "Exposed"
is a bit vague but
> > I wouldn't assume it extends to a client POSTing an entity. In
> > addition, there is vagueness of whether the MAY refers to the
use of
> > the Link header, or whether it refers to the acceptance of non-RDF
> > formats. @Steve: Can you clarify this LDP part, please? OPEN.
> 
> Ian, this is the requirement I was thinking of:
> 
> http://www.w3.org/TR/ldp/#ldpc-post-createrdf
> 
> Reading it again, I'm not sure it covers the non-RDF source case.
Steve,
> Arnaud?
> 
> > > > I think the examples should come after the normative
content which
> > > > defines the terms appearing in those examples.
> > >
> > > OK, how it's currently structured then?
> >
> > examples are in section 8 whilst 7 and 9 are normative. OPEN.
> 
> OK, I see. One thing I notice is the spec template does not have an
> examples section.
> 
> http://sspeiche.github.io/respec/examples/oslc/template-spec.html
> 
> I suggest we discuss on the next call.
> 
> > > > 7.1.1 "at least" seems redundant and/or I
don't think defined
> > > > anywhere.
> > >
> > > The intent is that it could be a LDP 1.1 or 2.0 compliant
as well.
> >
> > okay. so it is meant "MUST be LDP 1.0 compliant"?  OPEN.
> 
> I'd say no. An LDP 2.0 server might not be 1.0 compliant.
> The intent is we are compliant with some version of LDP, 1.0 or a
future
> version.

But you do not know that compliance with a future
version of LDP will be consistent with Attachment 3.0.

Eg if LDP 2.0 is not backwards compatible with 1.0,
how can you state in the Attachments 3.0 spec that 2.0 would be acceptable
(as you intend by writing "at least")?

> 
> > > > 7.2.1 holds attachments for only that resource - why
is this
> > > > necessary?
> > >
> > > The requirement is trying to say that there isn't just one
big container
> > > of all attachments for all resources on server. In other
words, all
> > > attachments in this specific container are for only this
resource.
> >
> > yes, this is what I understood.  My question is why make
this
> > constraint? A server should be free to organize its attachments/
> > resources as it sees fit.  What is lost by allowing, for
example,
> > two resource to share an attachment container?  OPEN
> 
> Do you have a scenario in mind?

I don't;  I'm only thinking of generality.

> 
> I think it makes things a little murkier for clients. If I POST to
the
> container, do I need to worry that I might be attaching something
to
> more than one resource?

Agreed, but why is this problematic?  As far
as I understand, two LDPCs can share members so a server could achieve
sharing in this way.  A downside of this is that the sharing is a
little less conspicuous to a client.  However, I will CLOSE as I don't
have a use case.


> 
> > > > 7.2.2 Why is http://open-services.net/ns/core\#AttachmentContainer
used
> > > > here when that term is also an rdf:type? Shouldn't
this be a distinct
> > > > term, say http://open-services.net/ns/core\#attachmentContainer
> > >
> > > I'm open to your suggestion. I'm not sure there is a convention
for link
> > > relations. It would mean that we define an additional URI,
which is OK.
> >
> > i would prefer to keep the terms separate, if that is acceptable
and
> > there are no arguments against.  Maybe a topic for the TC
to discuss
> > via email?  OPEN.
> 
> We should look at the link relation we use for UI preview in that
case so
> we're consistent. We use the RDF type as a link relation there as
well.
> 
> https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/
> specs/resource-preview.html#linkHeader
> 
> > > See example 8.6. The attachment container points to the
resource using
> > > ldp:membershipResource following the direct container membership
triple
> > > pattern.
> >
> > My question is how a server would do 7.2.3 - a resource indicate
in
> > its representation the oslc:AttachmentContainer(s) that can be
used
> > to make attachments to that resource.  What vocabulary term
would
> > link the resource to the container?  OPEN.
> 
> I guess I don't understand. Example 8.6 is meant to show how a server
> does 7.2.3. The container points to the resource, not the other way
> around, because this is how direct containers work in LDP. We have
the
> Link header if a client needs it, but you can still find the container
> just looking at the RDF.
> 
> If we add a property to the resource, we're repeating ourselves a
lot.
> We effectively have 3 links:
> 
> 1. The Link header
> 2. The direct container pointing to the resource
> 3. The resource pointing back to the container
> 
> I suggest we discuss on the next call.

okay.  I see this clause has been removed from
the draft.  We can discuss at TC meeting. ACCEPTED.

> 
> > > > 7.3.4 Is there a reason this is not a SHOULD?
> > >
> > > I am fine either way. I chose MAY because I didn't think
it was too
> > > important.
> >
> > suggest we discuss this one at the TC?  OPEN.
> 
> I think so.

okay. ACCEPTED

> 
> > > > 7.3.9 Standard HTTP. I don't see the need to be in
this document.
> > >
> > > This one is more debatable. A lot of clients might try to
simply remove
> > > the triple from the container instead of calling HTTP DELETE
on the
> > > attachment URI. Since there are multiple ways you might
try to delete
> > > the attachment, I think we should talk about it somewhere
in the spec. I
> > > can't recall off-hand what LDP says about removing containment
or
> > > membership triples. Maybe Arnaud or Steve can better comment.
> 
> Ian, OK to leave this in? Or move to a non-normative section?

Removal of an attachment (whatever ways there are)
should be those defined by LDP.  I see no reason for there to be Attachment-specific
normative statements since these are covered in LDP/HTTP.  Suggest
we clarify LDP spec. then come to decision. 

> 
> > > > 9. Is this spec trying to restrict the way in which
wdrs:describedBy
> > > > can be used when the object is an AttachmentDescriptor?
The cardinality
> > > > restriction doesn't apply to the object of links. Instead,
the spec
> > > > needs to state the relationship between a attachment
and its descriptor
> > > > (each descriptor describes exactly one attachment)
and an attachment
> > > > has at most one descriptor. The relation between these
resources is
> > > > represented using describedBy. I don't see why describedBy
is described
> > > > as an inverse property (inverse of what?) it is just
a link between two
> > > > resources.
> > >
> > > It's inverse meaning that it's not a property for
> > > AttachmentDescriptor. Rather, AttachmentDescriptor is the
object of an
> > > wdrs:describedBy triple. (The subject is the attachment
as in 8.6).
> >
> > We express cardinality constraints using resource shape.  But
here,
> > there is no resource whose shape is being defined - you are trying
> > to impose a cardinality constraint on the generic use of a property.
> > This doesn't mean anything.  We need to find another way
to express
> > the invariant.  OPEN
> 
> You make a good point. We have a problem in that the attachment is
a
> non-RDF source, so there's no shape. I'm open to suggestions. We could
> remove discussion of wdrs:describedBy from this section.

I don't think shape is useful here.  A server
choosing to create an attachment descriptor MUST link to it from the attachment.
 An attachment MUST NOT link to more than one descriptor.

> 
> > > > 9. Are there any restrictions (eg as in 7.4.4) that
restrict the
> > > > dcterms:title of an attachment descriptor? Can a server
accept
> > > > a change to dcterms:title and alter it as it does when
a client
> > > > supplies a Slug?
> > >
> > > The intent is that you can do a PUT on the AttachmentDescriptor
to
> > > update a title. I'm not sure if it's explicitly stated in
the spec.
> >
> > understood.  But, the title of the attachment is subject
to special
> > processing (Slug handling). A server MAY ignore a Slug or it
may
> > alter the Slug value.  I was looking to clarify whether
or not the
> > server can take the same liberties on a PUT of a new title.  OPEN.
> 
> We might discuss on the call. I'd say it's a 4xx error if the server
> can't use the title unchanged. The semantics of PUT are that the content
> completely replaces the resources. I'm not sure the server should
> silently change something in the PUT content.

Agreed.  I'll CLOSE this one.

> 
> > > > 9. I think http://open-services.net/ns/core\#AttachmentContainer
> > > > should be definned in this section (and as I have suggest
above),
> > > > http://open-services.net/ns/core\#attachmentContainer.
> > >
> > > I was actually considering removing the AttachmentContainer
class. I'm
> > > not sure it's necessary. We can simply use the LDP container
types.
> >
> > it would be useful for applications that support query over
> > resources.  Such a type would allow selection of attachment
> > containers by querying for that type.  I don't know this
to be an
> > important use case.  We could define this type but make
its use in
> > representations OPTIONAL.  OPEN.
> 
> I agree we keep the oslc:AttachmentContainer type. I'm not sold on
> oslc:attachmentContainer for the reasons above (my response on 7.2.3).

Since 7.2.3 has been removed, discussion on oslc:attachmentContainer
is moot.  CLOSED.

> 
> --
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU