W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

Re: ldp-ISSUE-11 (Server-managed properties): Do we need to define server-managed properties or do we leave them to applications? [Linked Data Platform core]

From: Sergio Fernández <sergio.fernandez@salzburgresearch.at>
Date: Mon, 04 Feb 2013 14:55:37 +0100
Message-ID: <510FBDD9.9000706@salzburgresearch.at>
To: Henry Story <henry.story@bblfish.net>
CC: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Raúl García Castro <rgarcia@fi.upm.es>, "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
Hi,

On 04/02/13 14:44, Henry Story wrote:
> Are you saying that a graph should be restricted that way? That seems too strong to me. What does
> make sense, as I argued in the thread "Estabilishing conversational context"
> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0032.html
> there may be properties on the LDPR<>  that is data that should probably
> appear in the LDPC on that resource, such as dcterms:modified and dcterms:creator
> and other relations similar to the ones you would find in an atom:entry (
> ie: the metadata for the resource ).

I'd suggest to restrict as less as possible, But we should be careful on 
mixing server and actual resource statuses, which may cause important 
conflicts on data as ISSUE-points. That's why we are suggesting to avoid 
such limitations on dcterms, for instance, and move to a LDP vocabulary 
to describe such status.

> If you want mechanisms to advertise restrictions on graphs for particular purposes
> then you should work on ISSUE-48 "Profile mechanism is Needed", and find some
> good use cases for it, so that we can then open it, with an idea as to what it would
> be to close it.

Since we are not agreeing on the basics, IMO profiles could come on a 
second phase.

Greetings,

-- 
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
Received on Monday, 4 February 2013 13:56:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC