Re: Blank Nodes Re: Toward easier RDF: a proposal

Related to that last email, there was earlier discussion about using
literals in any position in a triple. In Swift all of the basic types, int,
Boolean, string, etc, are implemented as structures behind the scenes. To
me this is analogous to converting all literals to blank nodes, so I'm
throwing that out there to see if that is an approach that possibly helps
with processing data, or with canonicalization efforts. Maybe it's a
practice that's already done, apologies if so.

Instead of these possibilities:

Subject:

IRI

Blank node

Literal

Predicate:

IRI

Blank node

Literal

Object

IRI

Blank node

Literal


With the conversion you are left only with these:

Subject:

IRI

Blank node

Predicate:

IRI

Blank node

Object

IRI

Blank node

Literal (and only inside a blank node)


Anthony

Relevant link here (section - Structures and Enumerations Are Value Types):

   -
   https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html


On Fri, Nov 30, 2018 at 2:06 AM Anthony Moretti <anthony.moretti@gmail.com>
wrote:

> I think there is an analogy to this in Swift and C# (and maybe other
> languages, these are just ones I'm familiar with):
>
>    - An IRI is represented by a *class* instance
>    - A blank node is represented by a *struct* instance
>
> Swift:
>
> class SomeClass {
> // class definition goes here
> }
>
> struct SomeStructure {
> // structure definition goes here
> }
>
>
> Classes are reference types, you check if one variable is *identical to* another
> variable using three equals signs, ===. This checks if they refer to
> exactly the same class instance. To me this is the same as checking whether
> they both refer to the same IRI.
>
> Structs are value types, you check if one variable is *equal to* another
> variable using two equals signs, ==. This checks if they are considered
> equal or equivalent in value, and what qualifies two instances being equal
> must be defined for every type. To me this is the same as having two blank
> nodes of type Address and having an agreed upon method of checking whether
> two Address instances are equal.
>
> If you have:
>
> struct Address {
>
> var streetAddress: String
>
> }
>
> var a = Address(streetAddress: "123 Sesame St")
>
> var b = Address(streetAddress: "123 Sesame Street")
>
>
> Then it would be up to the implementation of the *equals to* method,
> ==, within Address whether a == b would return true or false.
>
> In summary, the way this is addressed is by explicitly stating *as part
> of the language* that blank nodes can be compared by their composition,
> but that the process of comparison must be defined for each type.
>
> Anthony
>
> Some relevant links here:
>
>    -
>    https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html
>    -
>    https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/
>
>
>
> On Fri, Nov 30, 2018 at 1:54 AM Hugh Glaser <hugh@glasers.org> wrote:
>
>> Yes.
>> All very much agreed.
>>
>> Especially
>> > But we *can*
>> > give users better support for collapsing duplicate nodes if
>> > they follow good practices such as indicating keys -- provided
>> > that we devise a *convenient* notation for them to do so.
>>
>> And with guidance for different types of things, and best practice.
>> And maybe even collect together libraries that capture that best practice
>> in code,
>> which cause collisions across wider datasets.
>>
>> Essentially pushing out what many developers must be doing internally to
>> the external world.
>>
>> Best
>> Hugh
>>
>> > On 30 Nov 2018, at 02:29, David Booth <david@dbooth.org> wrote:
>> >
>> > On 11/29/18 6:12 PM, Hugh Glaser wrote:
>> > >> David Booth wrote:
>> > >> In my own experience, objects composed of literal attributes
>> > >> like this generally *do* form a composite key, though
>> > >> perhaps other RDF developers have had different experience.
>> > >
>> > > Since you ask :-)
>> > > I'm sorry to report that my experience is that they often don't.
>> >
>> > Fair enough.  I guess it depends a lot on the data origins.
>> >
>> > > . . .  So it would be folly to try to automagically generate URIs
>> > > for such bNodes in general - generated unique URIs or sufficiently
>> > > large random ones is the best that you can do.
>> >
>> > Agreed.  But I think my point still holds if a (composite) key
>> > can be conveniently indicated.
>> >
>> > > I think that if you consider *all* the properties, essentially
>> > > the SCBD, you might get away with it, almost always.
>> > > (As someone else pointed out.)
>> >
>> > I think that would be too risky to rely on.
>> >
>> > > . . . postal address
>> > > gets more difficult.  For a start, it is very unusual from
>> > > disparate datasets to get such well and uniformly formatted
>> > > addresses.  . . .
>> >
>> > Agreed.  Data cleaning and normalizing issues will always exist.
>> > But I think that's kind of a separate issue.  We cannot expect
>> > to automagically clean up people's dirty data.  But we *can*
>> > give users better support for collapsing duplicate nodes if
>> > they follow good practices such as indicating keys -- provided
>> > that we devise a *convenient* notation for them to do so.
>> >
>> > > And you need to decide what to do about missing fields.
>> >
>> > Missing key fields would prevent a standardized URI from
>> > being generated.  Missing non-key fields would have no impact.
>> >
>> > David Booth
>> >
>>
>>
>>