[Crm-sig] P90 etc.

Martin Doerr martin at ics.forth.gr
Thu Mar 15 17:43:21 EET 2018


Dear Conal, All,

Your arguments well taken, we are still obliged in formal ontologies to 
have explicit semantics.
The use described by Robert, which fulfills a real need, appears here as 
"emergent semantics"
from the community, which deviates fromthe W3C definition. I argue that 
this can be formulated in quite
precise terms, similar to what Robert formulated, and then there will be 
not need to talk about a lack of semantics.
I'd like to settle that until the end of the next meeting.

Let us distinguish
a) "values" which are points or areas in abstract mathematical spaces, from
b) symbolic objects in the form of linear sequences of 
machine-encodeable symbols
c) things that cannot exist in a digital form.

For c) no "value" can be given. We have the classical Pierce's referent 
and referree situation.
For those guys we use names, in particular identifiers.

Only objects of the form b) can reside on machines, if they have the 
storage capacity. So, from all things
a formal ontology talks about, only for those we think of not only 
talking about them in machines, but also
putting them into machines.

Then the question is: Is the identity-providing content in a Literal in 
my database, in a digital file, or on a paper document?

For a) , only subsets in finite machine encodeable form can reside in 
machines. In that case, the encoded form is not the a) guy itself, but a 
guy of type b), which is interpreted not as a type b), but a type a) guy.

Names in particular, if their identity is given as DEFINED as a linear 
sequences of machine-encodeable symbols, are type b) guys, but that does 
not imply the type c) guy they may identify or not.

Therefore, if we distinguish the 3 cases, we can have perfect semantics, 
and then talk about how to encode the cases.
Nothing mysterious, but we must understand the above distinctions, which 
are not within a logical space, but between logical spaces and the world 
around.

I hope this makes things clearer!

Comments welcome.

Best,

Martin





On 3/14/2018 12:01 PM, Conal Tuohy wrote:
>
>
> On 9 March 2018 at 04:39, Martin Doerr <martin at ics.forth.gr 
> <mailto:martin at ics.forth.gr>> wrote:
>
>
>
>     I recommend NOT to recommend rdf:value, because RDFS 1.1 defines:
>     "5.4.3 rdf:value rdf:value is an instance of rdf:Property
>     <https://www.w3.org/TR/rdf-schema/#ch_property> that may be used
>     in describing structured values. rdf:value has no meaning on its
>     own. "
>
>     As CRM-SIG, we cannot recommend a property without meaning. We do
>     ontology here, so the must be a minimal ontological commitment.
>     Are there other opinions?
>
>
> My opinion is that the real value of rdf:value is that it effectively 
> negates one of the weaknesses in the expressiveness of RDF, with 
> respect to the CRM.
>
> In RDF, a literal value is a second-class citizen: it has no 
> identifier, which makes it ineligible to appear as the subject of a 
> triple, so it can't have properties of its own. It can't be woven into 
> the "Web of Data". It can't effectively function as an "access point" 
> (in the library science sense) without some additional context.
>
> As Linked Data practitioners, we generally have literals like "Conal 
> Tuohy" as our source data for e.g. Appellations (and it's worth noting 
> that all of the formal examples of E41 Appellation are given as string 
> literals), but it's highly undesirable to encode an E41 Appellation 
> merely as a literal; such an encoding would make it impossible, either 
> for us, or for third parties, to annotate that name with properties of 
> its own ("A name of Irish origin ...").
>
> So we must mint an identifier, either a local ("blank node") 
> identifier -- or better still, an HTTP URI -- for that name (e.g. 
> "_conal_tuohy"), so that we can then attach other properties to that 
> identifier. We are left, finally, with the residual problem of how to 
> associate the literal name value itself ("Conal Tuohy") with that 
> identifier. This is where rdf:value plays a valuable role of 
> effectively just equating the literal with identifier; it is described 
> as having "no meaning on its own" precisely because it really plays 
> only a syntactical role. This is why I think it would be a mistake to 
> critique the use of rdf:value on the basis of it "lacking meaning of 
> its own"; it would be equivalent to criticising a relational database 
> for having an Appellation table with a column named "value".
>
> Regards
>
> "Conal Tuohy"
>
>
>
>
>     Taken the above definition in RDFS 1.1, I question both, the
>     precise use and the emerging good practice,
>     until better evidence:-).
>     Do you have better evidence?
>
>     It is up to crm-sig to decide, I present only my opinion here.
>
>     Best,
>
>     martin
>
>
>
>     On 3/8/2018 6:28 PM, Robert Sanderson wrote:
>>
>>     Martin,
>>
>>     Could you clarify why you have changed your mind about rdf:value?
>>
>>     > I recommend NOT to recommend rdf:value
>>
>>     In particular, in the last week you said:
>>
>>     “CRM-SIG normally works reactively: When a good community
>>     practice emerges, this is taken up.”
>>
>>     and
>>
>>     “Whatever the vast majority is  and rdf:value does the job, I
>>     have no objections to its use.
>>     Just define precisely what you use it for. We can add that to our
>>     guidelines. It is already standard rdf.”
>>
>>     Thanks,
>>
>>     Rob
>>
>
>     -- 
>     --------------------------------------------------------------
>       Dr. Martin Doerr              |  Vox:+30(2810)391625        |
>       Research Director             |  Fax:+30(2810)391638        |
>                                     |  Email:martin at ics.forth.gr <mailto:martin at ics.forth.gr>  |
>                                                                   |
>                     Center for Cultural Informatics               |
>                     Information Systems Laboratory                |
>                      Institute of Computer Science                |
>         Foundation for Research and Technology - Hellas (FORTH)   |
>                                                                   |
>                     N.Plastira 100, Vassilika Vouton,             |
>                      GR70013 Heraklion,Crete,Greece               |
>                                                                   |
>                   Web-site:http://www.ics.forth.gr/isl            |
>     --------------------------------------------------------------
>
>
>     _______________________________________________
>     Crm-sig mailing list
>     Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>
>     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>     <http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
>
>
>
>
> -- 
> Conal Tuohy
> http://conaltuohy.com/
> @conal_tuohy
> +61-466-324297


-- 
--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin at ics.forth.gr |
                                                              |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
                                                              |
                N.Plastira 100, Vassilika Vouton,             |
                 GR70013 Heraklion,Crete,Greece               |
                                                              |
              Web-site: http://www.ics.forth.gr/isl           |
--------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180315/66e173dc/attachment.html>


More information about the Crm-sig mailing list