Re: Comments on Linked Data Profile 1.0 Submission

Hi Leigh,

Sorry for slow follow-up as well. I've included some comments where 
needed.

Leigh Dodds <ld@talis.com> wrote on 07/11/2012 08:22:35 AM:

> From: Leigh Dodds <ld@talis.com>
> To: Steve K Speicher/Raleigh/IBM@IBMUS, 
> Cc: public-ldp-wg@w3.org
> Date: 07/11/2012 08:23 AM
> Subject: Re: Comments on Linked Data Profile 1.0 Submission
> 
> Hi Steve,
> 
> Sorry for slow follow-up to this. Glad the feedback is useful. A few
> comments in-line:
> 
> On 6 July 2012 19:24, Steve K Speicher <sspeiche@us.ibm.com> wrote:
> > ...
> > Leigh Dodds <ld@talis.com> wrote on 06/14/2012 05:37:31 PM:
> > ...
> >> 4.1.7 and 4.1.10
> >>
> >> These rules both require a minimum amount of data that must be
> >> provided for a BRP, specifically at least one rdf:type and at least
> >> one relationship to another resource. Both of these are expressed as 
a
> >> MUST which I think is far too strong. I might wish to initially
> >> capture some information about a resource, e.g. some simple literal
> >> values, and then progressively enrich [1] that description to add 
type
> >> and relationship triples. For example one common Linked Data
> >> publishing approach is to RDFize some data and then enrich it with
> >> additional links. These MUST requirements preclude that kind of 
usage.
> >>
> >> I understand the utility of having some minimal information to allow
> >> easier processing and navigation but think this is a SHOULD, not a
> >> MUST.
> >>
> >
> > I believe that 4.1.10 is written in a way that is not that clear.  It 
is
> > not to say that at least one relationship MUST be present, it is meant 
to
> > say that when it is present, it MUST be modeled as a simple triple.
> > I can see the point on 4.1.7, relaxing the rdf:type requirement but 
feel
> > that it weakens the profile a bit.
> 
> It'd be good to get that wording cleared up. It was confusing for me at 
least :)
> 
> I take your point about the rdf:type requirement. I'm thinking about
> scenarios where I'm steadily building up a dataset and may not have
> all of the data to hand initially. But this may not be a common
> scenario.
> 
> >> I'd also like to suggest that every resource SHOULD have a label
> > property [2].
> >>
> >
> > Seems like a good suggestion.
> 
> Thanks.
> 
> >> 4.1.9.
> >>
> >> I don't understand why servers MUST only use these datatypes. 
Granted,
> >> SPARQL only supports a subset of the XSD datatypes, but I don't think
> >> that necessarily impacts our use of datatypes in general. There are
> >> lots of examples of alternate XSD datatypes and custom datatypes in
> >> use in published Linked Data & RDF, so I'm curious as to why this
> >> extensibility should be removed.
> >>
> >> Personally I'd prefer to see a recommended "working set" of data
> >> types, but with guidance on the trade-offs of using additional and/or
> >> custom types. It would be useful to survey actual usage to see if
> >> there is already convergence on a common set.
> >>
> >
> > I think the primary scenario is that custom datatypes just limit what
> > clients can do with the values.  By limiting them, it enables a 
broader
> > class of client applications that can read, update, compare, etc these
> > values.
> 
> I understand the general aim, as clients do have more chance of
> working with data if they can understand it. One might argue that this
> applies just as well to schema terms as well as datatypes. For schema
> you've encouraged some best practices and convergence on standard
> terms. The same approach could be applied to datatypes.
> 
> There's a matter of degree here too. Truly custom datatypes are
> unlikely to be interoperable: there still isn't a well defined recipe
> for defining them. However the XML schema datatypes are all
> well-defined, if not always widely supported. As I pointed out, I
> think more of them are in common use than the subset recommended in
> the profile.
> 
> In this kind of standardisation effort I think its worth surveying
> usage to determine current practice and deciding the best route
> forward.
> 

Seems like a good suggestion, do you have any good references to start 
with?

> The profile current starts from a very prescriptive position, but I'm
> not convinced that's necessary. An alternative approach would be to
> identify a common set of datatypes to encourage further convergence,
> with explanations of trade-offs.
> 
> >
> >> 4.1.13.
> >>
> >> Again, I'm hesitant about the use of MUST here. I think proper use of
> >> ETags is essential and a server should go to lengths to provide 
ETags.
> >> But creating valid "deep ETags" could place additional burden on a
> >> server.
> >>
> >> For example I notice that the profile says nothing about what
> >> information is provided when one de-references a BPR. If I were to
> >> provide a Symmetric Bounded Description, e.g. to faciliate browsing,
> >> then I will need to generate an ETag based on the state of a number 
of
> >> resources.
> >>
> >> Clearly an implementation can use coarse-grained ETags (e.g. based on
> >> dataset modification), but that's less useful. Perhaps the Working
> >> Group should consider some guidance on ETag generation, and the
> >> trade-offs of not supporting them (e.g. inability to do conditional
> >> PUT).
> >>
> >
> > Good points, we don't want to over burden servers but we want them to 
do
> > the right thing.  Seems like a good one to spend a little more time
> > investigating this, getting feedback from others in the WG, and 
crafting
> > the right set of guidance around ETags.
> 
> OK, great.
> 
> >> 4.4.1
> >>
> >> The rule doesn't note which media types must be supported for a PUT.
> >> I'd suggest that the rule should be that a server MUST support a PUT
> >> using any of the RDF serialisations it supports via a GET. So
> >> application/rdf+xml and possibly text/turtle.
> >>
> >> It might also be useful to reference use of OPTIONS requests to
> >> advertise PUT, PATCH support; use of Accept-Patch, etc. A section on
> >> OPTIONS might be useful to add in general.
> >>
> >
> > Good suggestions as well.  I wonder why OPTIONS is needed if we 
already
> > have HEAD + Allow, what additional data would be needed in a 
specialized
> > OPTIONS response?
> 
> Yes, I think support for OPTIONS is needed even if HEAD + Allow is
> possible. A generic HTTP client may well issue an OPTIONS request, so
> ensuring that is implemented by servers is a good thing, IMO.
> 
> One deployed use of OPTIONS is in CORS. User agents may issue
> pre-flight requests using OPTIONS. This would require servers to
> return additional CORS specific headers.
> 
> >> 4.4.7.
> >>
> >> I wonder if it would be useful to consider how these additional
> >> constraints could be advertised or discovered by clients?
> >>
> >
> > You fell for our trap.  That is currently left out of the member
> > submission but covered by the charter.  We started specifying 
something
> > but decided to defer it until we got a basic set of rules in place. We
> > have some high-level definition for how these constraints are 
specified
> > [1].  It reminds me I need to update this article to make the 
submission.
> 
> Heh. Will look forward to seeing that.
> 
> >> 4.8.
> >>
> >> I am uneasy to see recommendations about ranges of properties that 
are
> >> at odds with their official definition. Encouraging re-use is good
> >> practice, but redefining existing properties is not.
> >>
> >> Also, suggesting that dct:title & dct:description should only refer 
to
> >> an XML Literal flies in face of common usage AFAICT.
> >>
> >> 4.8.3.
> >>
> >> I'm confused by the recommendation for use of rdfs:label only in
> >> vocabulary documents. rdfs:label is used very, very commonly as a
> >> generic labelling property so already has well-deployed use outside 
of
> >> vocabularies. Clearly there are alternates (e.g. skos:prefLabel) but
> >> rdfs:label is a useful fall-back that is already understood by many
> >> Linked Data clients.
> >>
> >
> > We were trying to stay true to the intended and defined usage [2], 
which
> > states:
> > "rdfs:label is an instance of rdf:Property that may be used to provide 
a
> > human-readable version of a resource's name."
> > and initially it states:
> > "This specification describes how to use RDF to describe RDF 
vocabularies.
> > This specification defines a vocabulary for this purpose..."
> >
> > Which reads to us the if rdfs:label is used, then it is describing a 
the
> > name of resource that is to be used in a vocabulary.
> >
> > Though if general usage of rdfs:label is used in practice as just "a 
label
> > on the resource", perhaps the specification should be updated to match
> > usage.
> 
> Yes, rdfs:label is widely used as "just a label". See:
> 
> http://www.aifb.kit.edu/images/c/c0/LabelsInTheWebOfData.pdf

> 
> Usage has evolved from the definition. I agree that the specification
> ought to be updated. One for the RDF WG group I think.
> 
> However the re-definition of dc:title & description still doesn't seem 
correct.
> 
> >> Secondly, I don't understand the recommendation for the range of
> >> rdfs:label to be a Resource? Is that a typo?
> >>
> >
> > It is a typo.
> >
> >> 5.1
> >>
> >> I don't follow this rationale for having separate container 
resources:
> >>
> >> "You might wonder why we didn’t just make
> >> http://example.org/netWorth/nw1 a container and POST the new asset
> >> directly there. That would be a fine design if
> >> http://example.org/netWorth/nw1 had only assets, but if it has
> >> separate predicates for assets and liabilities, that design will not
> >> work because it is unspecified to which predicate the POST should add
> >> a membership triple."
> >>
> >> Wouldn't a POST of:
> >>
> >> <http://example.org/netWorth/nw1> o:asset
> >> <http://example.org/netWorth/nw1/assetContainer/a3>;
> >>
> >> ....communicate the necessary information? In the case of server side
> >> URI assignment a blank node could be used for the new asset. What am 
I
> >> missing?
> >>
> >
> > A POST to what URL?  I also don't follow the usage of a blank node for
> > this.  Perhaps we need a separate thread on this.
> 
> OK. I meant a POST to: http://example.org/netWorth/nw1

> 

This POST seems to be acting like a PATCH from what I can tell you are 
suggesting.  Where you are "creating" a new triple only, not necessarily a 
new asset resource.

> >> I'm a little confused about how to go about updating resources that
> >> are associated with a BPC. To test my understanding and taking an
> >> example from the specification:
> >>
> >> <http://example.org/netWorth/nw1/assetContainer>
> >>    a bp:Container;
> >>    bp:membershipSubject <http://example.org/netWorth/nw1>;
> >>    bp:membershipPredicate o:asset.
> >>
> >> <http://example.org/netWorth/nw1>
> >>    a o:NetWorth;
> >>    o:asset
> >>       <http://example.org/netWorth/nw1/assetContainer/a1>,
> >>       <http://example.org/netWorth/nw1/assetContainer/a2>.
> >>
> >> a. If I want to update the rdf:type of
> >> <http://example.org/netWorth/nw1>, do I just PUT an updated
> >> description to its URI?
> >>
> >
> > Yes
> 
> OK.
> 
> >> b. If I want to add a new o:assert relationship for that resource,
> >> then I must POST to <http://example.org/netWorth/nw1/assetContainer>?
> >> If so, how do I determine that, via a SPARQL query?
> >>
> > Determine the container URL?  From the fact that the subject URL type 
is
> > of bp:Container.
> 
> Yes, how do I determine the container URL. For example, if I have a
> description of http://example.org/netWorth/nw1, e.g. by de-referencing
> its URI, then I don't know what the container is, as there is no
> relationship from the resource to its container.
> 
> I would need some other method to determine that relationship and find
> the container URL. A POST to the resource URL would be simpler.
> 

Most like a LDBP server would include additional triples so I client would 
know what container it was part of.  POST'ing may work but I could see 
cases where some resources could have multiple containers with the same 
resource type and servers wouldn't know which container it was directly 
for.  The representation of the resource should have the container 
information

> >> c. What if I just PUT an updated description to
> >> <http://example.org/netWorth/nw1> that adds or removes o:asset
> >> relationships?
> >>
> >
> > PUTing would replace the resource defined a that Request-URI with the
> > representation in the request.  So if the representation has 
added/removed
> > relationships and the server supported PUT to update, then I believe 
it
> > would update it as you describe.
> 
> OK. If I can do that, then I'm really not understanding the role of
> the container resources :/
> 

Container is very simple: POSTing to it creates the resource from 
representation and adds to the membership of the container.

> >> d. What if I first DELETE
> >> <http://example.org/netWorth/nw1/assetContainer> and then want to
> >> update its o:asset relationships?
> >>
> >
> > Perhaps we'd want to say more about what happens when deleting 
containers.
> >  I would expect that most implementations that processed this request
> > would also remove the relationships.
> 
> OK.
> 
> >> e. If I want to add a dct:description property to
> >> <http://example.org/netWorth/nw1/assetContainer> then do I PUT to
> >> <http://example.org/netWorth/nw1/assetContainer?non-member-properties

>
> >> or can I just PUT to <http://example.org/netWorth/nw1/assetContainer>
> >> ?
> >>
> >
> > By using <
> > http://example.org/netWorth/nw1/assetContainer?non-member-properties> 
as
> > request-URI to add the dct:descriptions allows you do it without 
having to
> > preserve the members on update.
> >
> >> 5.1.2
> >>
> >> Retrieving non member properties might be better described as another
> >> example of a Bounded Description [3]. In this case it is a subset of 
a
> >> Concise Bounded Description of a resource. A Linked Data server might
> >> want to support clients in requesting different bounded descriptions,
> >> beyond that of containers.
> >>
> >
> > Been a while since I looked at this.  We looked at a number of 
approaches
> > to do this and I should probably surface this in the discussion.  We 
can
> > include the Bounded Description with that evaluation.
> 
> That would be useful, thanks.
> 
> L.
> 
> -- 
> Leigh Dodds
> CTO, Talis Systems Ltd
> Mobile: 07850 928381
> http://talis.com

> http://kasabi.com

> 
> Talis Systems Ltd
> The Exchange
> 19 Newhall Street
> Birmingham
> B3 3PJ
> 

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

Received on Sunday, 22 July 2012 15:11:37 UTC