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

[Samuel Padgett <spadgett@us.ibm.com>]

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.

> > > 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 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?

> > > 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.

> > > 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.

> > > 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?

> > > 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.

> > > 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.

> > > 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).

--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC