Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

Guess I'm saying two things.

The first:
type: rdfs:Datatype should be a way that consumers of a graph can
understand that value semantics apply, that if they like they can ignore
any ID if it exists, that the value is fully described by its properties.
It should be a way for publishers of a graph to say all that without having
to create an accompanying literal syntax.

In Swift for example, I can say either of:

    *class* Circle {
        center: coordinate1,
        radius: 10,
    }

    *struct* Circle {
        center: coordinate1,
        radius: 10,
    }

The first implies reference semantics, the second value semantics.

So if I'm able to use rdfs:Datatype in that way, then during processing,
blank nodes whose types are instances of rdfs:Class should be given a URI
(using UUIDs for example), but blank nodes whose type is an instance
(singular) of rdfs:Datatype shouldn't.

The second:
If I'm able to do that, then literal syntax only exists as syntactic sugar
for blank nodes whose type is an instance of rdfs:Datatype. So if all blank
nodes should become a subset of the graffiti of S then all literals should
too.

The whole issue is interesting to me because since 2015 iOS developers have
been forced to understand value semantics with the introduction of structs
in Swift, and I see parallels in how the RDF community continuously
struggles with blank nodes. I feel like rdfs:Datatype could have a bigger
role to play than it currently does and potentially help clarify things.
But I'm no logician, it's just an intuition of mine that could be very very
very wrong, I don't know 😅

Anthony

On Tue, Jul 7, 2020 at 6:41 PM Thomas Passin <tpassin@tompassin.net> wrote:

> On 7/7/2020 8:36 PM, Anthony Moretti wrote:
> >     In this specific case it could be rdf:type time:DateTimeDescription
> >     from OWL-Time.
> >     See https://www.w3.org/TR/owl-time/#time-position
> >
> >
> > That's right, Simon. Correct me if I'm wrong though, using
> >
> >      type: time:DateTimeDescription
> >
> > versus:
> >
> >      type: xsd:DateTime
> >
> > makes one a reference type and the other a value type.
>
> What I have seen time and again in modeling is that you start out
> thinking you can use a simple literal value, but later you find it needs
> to become a composite.  Say you are modeling a project.  It has a
> budget, and that's just a number, a literal value.  But soon you need it
> to have a capital improvement component and a maintenance component, and
> you find you also need it split out into quarterly segments.  Your nice
> simple literal has become a complicated construction.
>
> So you might as well plan on that happening, to make it easy when it does.
>
> TomP
>
>
> > The "Description" suffix leads to a little confusion I think. By the
> > same logic xsd:DateTime could be named xsd:DateTimeDescription, I think
> > time:DateTime might have been sufficient. The Circle example might be a
> > better example in any case.
> >
> > Anthony
> >
> > On Tue, Jul 7, 2020 at 5:32 PM Laufer <laufer@globo.com
> > <mailto:laufer@globo.com>> wrote:
> >
> >     It is a poetic license. And it is a concise way of expressing my
> >     understanding of how to denote everything that exists, including us.
> >
> >     Laufer
> >
> >     Em 07/07/2020 20:23, Patrick J Hayes escreveu:
> >
> >>     Ahem. Use/mention confusion. We are not bnodes. We can be /denoted
> >>     by/ bnodes. But since that is true of everything that exists, it
> >>     isn't a terribly great accomplishment.
> >>     Pat
> >>
> >>         On Jul 7, 2020, at 3:44 PM, Laufer <laufer@globo.com
> >>         <mailto:laufer@globo.com>> wrote:
> >>
> >>         we are blank nodes
> >>
> >>         Cheers,
> >>         _:x  :name  "Laufer"
> >>
> >>         ---
> >>
> >>         劳费尔
> >>
> >>         .  .  .  .. .  .
> >>         .        .   . ..
> >>         .     ..       .
> >>
> >     ---
> >
> >     劳费尔
> >
> >     .  .  .  .. .  .
> >     .        .   . ..
> >     .     ..       .
> >
>
>