Re: Data Model Assumptions

+1 to what Ivan and Raphaël have said.


I would add a further caution that flexibilty in object-property pairings
always comes at a high price in both interchange and interoperability.
These kinds of data models are always arbitrary and ad hoc (and I mean
arbitrary and ad hoc in the non-pejorative way). They're simply specialized
to the specific needs of particular domain-communities.

Rather than looking at the model and asking what is the minimum that the
Javascript developer community needs, perhaps it would be more constructive
to ask what can the Linked Data community live without. Because we're
trying to build a broadly general model, that will satisfy the needs of
multiple communities, it's necessary to identify the "lowest common
denominator," so to speak, among those communities. If we place one
community over another then things are likely to fall apart. The rub is,
because of the open world assumption, the LD community needs much more
structure than the Javascript developers. Linked Data / SemWeb developers
are not free to make the same kinds of assumptions about the data and the
users that other flavors of developer are.

This is essentially why we didn't model roles on the bodies to start with.
Linked Data folks have to pay a steep price in verbosity to represent that
kind of information in the model.

Regards,

Jacob


_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

On Tue, Aug 18, 2015 at 8:34 AM, Raphaël Troncy <raphael.troncy@eurecom.fr>
wrote:

> Dear all,
>
> I would do a +1 for the very good set of precisions brought by Ivan, I
> concur to everything which is said in this message. I would bring the
> following clarification note:
>
> * unusual, but apparently optional, "predicate" names (e.g. "hasBody")
>>>
>>
>> That is not part of any kind of any RDF standard, it is just the habits
>> that a particular community has (often inherited from people who defined
>> vocabularies, library catalogues, etc, way before even the Web existed).
>>
>
> The RDF data model results in a DAG (Directed Acyclic Graph). This means
> that the predicates are directed (in your image representation, you have a
> left side and a right side of the arrow). RDF does not say more than this.
>
> As Ivan pointed out, in practice, some people felt that this "direction"
> of the predicate should be conveyed in the predicate name, thus the pattern
> you encounter under the form "hasXXX" or "isXXXBy" and that apparently you
> found "unusual" or even perhaps "awkward".
>
> Now, let's imagine that you encounter the predicate name "broader", and
> more precisely, the statement "x broader y" ... do you know if x is broader
> than y or if this is the over way around? You may want to ask SKOS that has
> an opinion on this [1]. The truth is that if you ask the developers(*), you
> will get 20% of the people that think this is one way, 20% that thinks this
> is the other way and 60% that just think this was a terrible predicate name
> since they have to systematically look at the spec [1]! I'm not saying that
> the hasXXX pattern should always been used, I'm just trying to explain you
> where it comes from ... releasing the ambiguity that "some" predicate names
> naturally have when providing a cue of their direction.
>
> Best regards.
>
>   Raphaël
>
> (*) Very informal but still serious poll among the many debates that took
> place when implementing the SKOS specification.
>
> [1] http://www.w3.org/TR/skos-reference/#broader
>
> --
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Multimedia Communications Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/
>
>