Re: Blog post about "Provenance in RDF-star"

Pat,

The fact that something is beside the point depends on one's opinion and 
perspective, but it also depends on what is "the point".

Here it seems you are arguing about a different point. I completely 
agree with the fact that there are different ways of modelling or 
designing a representation for many things, and many of them are valid. 
I never pretended otherwise. Your examples are certainly relevant 
(atom/city/etc), but again, this is beside the point I'm trying to make.

My point is the following: if someone defines a property "foaf:name" and 
describes its intended meaning as "the relation between a person and 
their name", followed by an example such as:

az:me  foaf:name  "Antoine Zimmermann" .

then it comes to no one's surprise that a string literal is used in the 
object position. Other models are valid, for sure, where an IRI is used 
to identify a name, and more details about the names can be expressed. 
But at least, the choice of a literal here is not regarded as a bad design.

However, if someone defines a property "foaf:knows" and describes its 
intended meaning as "a relation between a person and someone they know", 
followed by an example such as:

az:me  foaf:knows  "Pat Hayes" .

then it is legitimate to consider that the example is mistaken. This 
kind of confusion between a casual name and an identifier is regarded as 
a mistake in databases, in object oriented programming, and in modelling 
knowledge in general. If someone has a relational table "Employee", with 
a numeric primary key, and there is a column "manager", where manager is 
intended to identify an employee that manages (or supervise) the given 
employee, then it is a mistake to use a String. One should use a foreign 
key that refers to the primary key of the Employee table.
Similarly, if there is a class Employee in an object oriented programme, 
and one wants to introduce an attribute "knows" that connects the 
employees to the list of people they know, it is a bad design to define 
"knows" as an array of strings. One should use an array (or hashSet, or 
List, or any kind of collection) of objects of type Employee.
Any student who is learning DBMS or OOP would be considered mistaken if 
they used strings to model the reference to employees.

Following the same idea, I claim that: if Pierre-Antoine defines the 
property "ex:accordingTo" as intended to represent a relation between a 
claim and a person, followed by the example:

<<:empl38 :jobTitle "Assistant Designer">> ex:accoridngTo :empl22 .

then there is a mistake in the example (or in the model). The RDF-star 
node <<:empl38 :jobTitle "Assistant Manager">> denotes a structure that 
involves the specific URIs ":empl38" and ":jobTitle", and involves the 
specific string literal "\"Assistant Manager\"^^xsd:string", which can 
arguably be considered a bad way of modelling a claim.


But in the case of RDF-star, the fact that a quoted triple does not 
denote a claim in the broad sense of the term [*] is hidden in the 
formal definition of the semantics that few people will be diligent 
enough to check (See 
https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#rdf-star-semantics). 
This kind of blog post that Pierre-Antoine authored may lead to 
inconsiderate usage of the RDF-star model, and therefore, I consider it 
to be misleading.


The problem in RDF-star documentation and literature, is that this 
confusion between merely being a claim, and being a thing attached to 
specific URIs and literals, is maintained throughout all examples.

Modelling the claims themselves (and not the RDF representation of them) 
is a desirable feature for many use cases. So, if RDF-star is presented 
as able to address these use cases, a lot of people may be attracted to 
it with the wrong assumptions on what RDF-star can truly represent.


--AZ


[*] To be precise, a quoted triple denotes something that is related to 
a specific predicate IRI, at least, and possibly a subject IRI, an 
object IRI, and/or an object literal. So, a quoted triple, rather than 
denoting a claim in the common understanding, denotes "a claim attached 
to a certain predicate IRI". This nuance is hidden in the documentation.



Le 07/02/2022 à 20:32, Patrick J. Hayes a écrit :
> 
> 
>> On Feb 4, 2022, at 2:22 AM, Antoine Zimmermann 
>> <antoine.zimmermann@emse.fr <mailto:antoine.zimmermann@emse.fr>> wrote:
>>
>> ... most people, I believe, would accept that a name can be a 
>> character string (and vice versa). ... We identify names and character 
>> strings all the time, and it is fine. If you are working in the field 
>> of lexicography and philology, you may want to identify words, word 
>> representations, word senses, etc. with individual URIs, but I'd say 
>> it is beside the point.
> 
> But we can say the same about many topics, perhaps all of them.
> 
> Most people would accept that one atom of an element is just like 
> another. We do that all the time, and it is fine. If you are working in 
> the field of nuclear chemistry you may want to identify different 
> isotopes, such a C-14 and C-12, with individual URIs, but I'd say it is 
> beside the point.
> 
> Most people would accept that a city is just a place. We do that all the 
> time, and it is fine. If you are working in the field of civic 
> administration you may want to identify different administrative 
> entities, such as the City of London and Greater London, with individual 
> URIs, but I'd say it is beside the point.
> 
> And so on.
> 
> "I'd say it is beside the point" simply means "I am not interested in 
> that particular distinction and am happy to ignore it", but of course 
> others may differ. Whenever you take that position you implictly exclude 
> some users, by making it impossible for them to speak of what interests 
> them.
> 
> Pat

-- 
Antoine Zimmermann
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 49 97 02
http://www.emse.fr/~zimmermann/

Received on Tuesday, 15 February 2022 16:32:48 UTC