RE: Profiles in Linked Data

Kingsley,

On Tuesday, May 12, 2015 2:58 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.
> 
> Terms from a vocabulary or ontology do not change the topology of an RDF
> statement represented as graph pictorial. Neither do additional
> statements that provide constraints on the subjects and objects of a
> predicate. It is still going to be an RDF 3-tuple (or triple).

Well yes, but that's not my point. I'm not talking about clients and servers negotiation the triple structure of the RDF data. I'm talking about that servers need a way to describe what vocabularies they use to describe their data, including things like cardinalities (a person will have the type foaf:Person and will have exactly one foaf:birthday and maximum one foaf:dnaChecksum). When we describe persons in our linked data service, we will say that a person will have the type gndo:DifferentiatedPerson, one or more gndo:dateOfBirth (there are cases where researchers dispute the exact birth date so we list all of them...), exactly one gndo:preferredNameForThePerson etc. etc. For lack of a better term I have chosen to call those descriptions "profiles". Perhaps "shapes" is a better choice. It has nothing to do with triple structure.

> >> >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?
> 
> RDF data has one shape. Use of terms from a vocabulary or ontology don't
> change the shape of RDF document content.
> 
> "Profiles" are a means of representing preferences. Seeking terms from a
> specific vocabulary or ontology in regards to RDF document content is an
> example of a preference.
> 
> You can use "rel=profile" as a preference indicator via HTTP message
> exchanges between clients and servers.

OK. So here we agree. The use of the Link header with rel=profile was one of my original suggestions...

Best,

Lars

Received on Monday, 18 May 2015 13:03:13 UTC