š
š
09.07.2014, 22:44, "Paul Gearon" <gearon@gmail.com>:
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.
š
š
I earlier wrote in this mailing list that I load new RDF files dynamically. This may cause that a previously valid data become invalid. I don't want my data suddenly become invalid when it was valid earlier (and probably already used, so I could not remove it).
š
It can't be enforced by OWL
š
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.
š
š
Manually by my application.
š
š
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.
š
š
My question is whether I can check programmatically whether a node is blank.
š
<snip/>

š
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.
š
š
It is exactly the purpose: to make it impossible to accidentally load more data that conflicts with the unnamed resource.
š
š
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
š