Re: An alternative RDF

Others will have a more informed opinion, but if I can address a couple of
your comments below...


On Wed, Jul 9, 2014 at 2:59 PM, Victor Porton <porton@narod.ru> wrote:

> As you see from my earlier messages to this mailing list, I had a trouble
> to process data combined from several different RDF files.
>
> Recently I have thought is that (the way I use) RDF is a wrong tool for my
> task!
>
> Consider this Turtle code:
>

<snip/>


> The trouble is that there may be no more than one :precedence. If we load
> data from an other RDF file, nothing prevents them be merged in such as way
> that there may be more than one :precedence for the same object, so
> rendering data inconsistent and forcing the programmer (me) to do something
> with a data which once was consistent but then suddenly became inconsistent.
>
> In my opinion, this trouble is from essence of RDF itself.
>

Pure RDF provides structure, but very little of semantics. Consequently the
semantics (such as single cardinality properties) must be provided by the
application or another layer of modeling such as OWL (owl:maxCardinality),
which in turn would be enforced by the application. RDF is flexible, which
allows individuals to encode inconsistent data that passes simple
validators. This does not make it useless, but does require it to be used
with care.

If you require a data structure where violating cardinality would result in
a syntax error, then RDF is not appropriate. What you are choosing is
whether validation is performed by a syntax checker, a model validator, or
manually by your application. In many situations that decision may be
arbitrary and a matter of style, rather than leading to some absolute
notion of correctness.


> We should do something either modifying the RDF specification, or creating
> a new formal language to describe objects which cannot be merged from
> several files in an inconsistent way.
>
> One way to solve it inside RDF is to add blank nodes, like:
>
> @prefix : http://portonvictor.org/ns/trans/ .
> <http://example.org/the-transformation> :transformation-data [
>
<snip/>

>         ]
> ].
>
> This way http://example.org/the-transformation becomes an object which
> cannot be "amended" into an inconsistent state by loading one more RDF
> file. We can provide an other data for
> http://example.org/the-transformation but it would be a separate object,
> which may have single :precedence, etc. Even if the second object (sharing
> the same resource URL) is invalid (say has more than one :precedence), the
> first object (above described) remains valid.
>
> However RDF parsers generate IDs (like _:genid1) where unnamed nodes are
> inserted. I am not sure whether a non-appropriate information may be
> inserted from an other RDF file using an ID like _:genid1. (Can it?)
>

I am not certain I have understood your question correctly, but it seems
that you are asking if by parsing 2 files that contain blank nodes then is
it possible for them to be accidentally resolved to refer to the same node.
Is that right? If so, then the answer is no, they cannot. Even if two blank
nodes are explicitly using the same blank node label, so long as they
appear in separate documents they will still be treated as different nodes.

The only way to have nodes resolve to the same resource is if:
- They have the same Identifier (an IRI)
- They participate in relationships that are described by OWL such that the
nodes must be the same resource.

The second case will only apply in the case that the system for storing the
RDF is capable of such inferences. Otherwise the nodes will be always
stored separately, even if they can be proven to represent the same node.



> Also the last code example is a little ugly: What is a reason to put the
> top-level http://example.org/the-transformation inside
> `:transformation-data [ ... ]` container, while the lower levels of the
> data tree (as presented above) are not in containers? Is it consistent with
> intuition?
>

You have created a transformation that has no identifier, and associated it
with a named resource that has no information (beyond the
:transformation-data property). This does not seem to provide any benefit,
except to make it impossible to accidentally load more data that conflicts
with the unnamed resource. But as I said above, this should either be
handled directly by an application, or if you want to automate it then by
describing with OWL.


So, we need to decide whether we can store such objects in RDF or should
> RDF be somehow amended or even replaced with an other standard. What I have
> described above is a serious fundamental problem and it needs to be
> addressed!
>
> --
> Victor Porton - http://portonvictor.org
>
>

Regards,
Paul Gearon