Re: Profiles in Linked Data

On 13/05/2015 12:12, Martynas Jusevičius wrote:
> Lars,
>
> first of all, a SPARQL query can be converted to RDF graph using SPIN
> syntax: http://spinrdf.org/sp.html
>
> In my mind the RDF Shapes WG is about RDF validation, and hopefully
> will also be based on SPIN. I'm not interested in the part about
> non-SPARQL shapes as this is mostly politics at play. If you want to
> do practical development, SPARQL is all you need.

That is a political statement Martynas and therefore denies your 
previous sentence.

>
> Moreover, Shapes WG is very new while SPARQL has been around for 10
> years. You wrote "not all clients want to talk sparql" -- but somehow
> those clients will want to talk Shapes? Makes no sense to me.

But it does to others.

>
> I'm still of the opinion that you are looking in the wrong places.
> Have you actually tried SPARQL for this? What did not work?

I don't think it is reasonable to expect data portals that harvest 
metadata from other portals to include a SPARQL engine just to check 
that data conforms to a profile, like DCAT-AP. That should be possible 
without having to build or include a SPARQL engine which would be 
overkill for what is essentially a pretty simple task.

SPIN does a really good job and in many circumstances it is the right 
tool. But not all. IMHO we need a more flexible approach, one that can 
handle simple cases without SPARQL. Now, whether the SHACL work is the 
answer is, mercifully, a question others are answering.

Phil.


>
> Martynas
>
> On Wed, May 13, 2015 at 12:42 PM, Svensson, Lars <L.Svensson@dnb.de> wrote:
>> Martynas,
>>
>>> this is a very simple answer that I have given you before: a shape of
>>> RDF data is defined as SPARQL query. There are no two ways about it.
>>
>> Hmm, the list of deliverables of the data shapes wg [1] mentions an RDF vocabulary to describe shapes, a set of semantics _possibly_ defined as SPARQL operations, etc. It says that one possibility is to use SPARQL queries to evaluate shapes against RDF graphs. At least to me, that doesn't mean that the shape is defined as a SPARQL query, but as an RDF graph.
>>
>> [1] http://www.w3.org/2014/data-shapes/charter#deliverables
>>
>> Best,
>>
>> Lars
>>
>>> On Tue, May 12, 2015 at 2:18 PM, Svensson, Lars <L.Svensson@dnb.de> wrote:
>>>> Kingsley,
>>>>
>>>> On Monday, May 11, 2015 9:00 PM, Kingsley Idehen wrote:
>>>>
>>>>> We have to be careful here. RDF Language sentences/statements have a
>>>>> defined syntax as per RDF Abstract Syntax i.e., 3-tuples organized in subject,
>>>>> predicate, object based structure. RDF Shapes (as far as I know) has nothing
>>> to
>>>>> do with the subject, predicate, object structural syntax of an RDF
>>>>> statement/sentence. Basically, it's supposed to provide a mechanism for
>>>>> constraining the entity type (class instances) of RDF statement's subject and
>>>>> object, when creating RDF statements/sentences in documents. Think of this
>>> as
>>>>> having more to do with what's regarded as data-entry validation and
>>> control, in
>>>>> other RDBMS quarters.
>>>>
>>>> The charter of the data shapes WG [1] says that "the product of the RDF Data
>>> Shapes WG will enable the definition of graph topologies for interface
>>> specification, code development, and data verification", so it's not _only_ about
>>> validation etc. My understanding is that it's somewhat similar to XML schema
>>> and thus is essentially a description of the graph structure. As such, it can of
>>> course be used for validation, but that is only one purpose.
>>>>
>>>>> The function of the "profile" I believe you (and others that support this) are
>>>>> seeking has more to do with enabling clients and servers (that don't
>>> necessarily
>>>>> understand or care about RDF's implicit semantics) exchange hints about the
>>>>> nature of RDF document content (e.g., does it conform to Linked Data
>>>>> principles re. entity naming [denotation + connotation] ).
>>>>
>>>> No, my use of "profile" is really a "shape" in the sense of the data shapes wg.
>>> Some of their motivations are what I'm envisioning, too, e.g.
>>>>
>>>> * Developers of each data-consuming application could define the shapes
>>> their software needs to find in each feed, in order to work properly, with
>>> optional elements it can use to work better.
>>>> * Developers of data-providing systems can read the shape definitions (and
>>> possibly related RDF Vocabulary definitions) to learn what they need to provide
>>>>
>>>>> Cut long story short, a "profile" hint is about the nature of the RDF content
>>> (in
>>>>> regards to entity names and name interpretation), not its shape (which is
>>>>> defined by RDF syntax).
>>>>
>>>> OK, I stand corrected: My question is: How can clients and servers negotiate
>>> shape information?
>>>>
>>>> Best,
>>>>
>>>> Lars
>
>

-- 


Phil Archer
W3C Data Activity Lead
http://www.w3.org/2013/data/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Wednesday, 13 May 2015 11:42:41 UTC