- From: Victor Porton <porton@narod.ru>
- Date: Wed, 09 Jul 2014 22:35:43 +0300
- To: SW-forum Web <semantic-web@w3.org>
Moreover to warrant consistency of data we need to ensure that <http://example.org/the-transformation> :transformation-data [ ... ] . is represented with an unnamed link node. Is it OK if my program will check whether the link note is unnamed and trigger an error if it is named (is an URL) and so can be accessed (and damaged) from an other RDF file? 09.07.2014, 22:06, "Victor Porton" <porton@narod.ru>: > 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: > > @prefix : http://portonvictor.org/ns/trans/ . > <http://example.org/the-transformation> > a :transformer ; > dc:description <http://...> ; > # Other Dublin Core metadata. > :source-namespace <...> ; > :target-namespace <...> ; > :precedence <...> ; > :script-data [ > a :xslt ; > :version "2.0" ; > :script-url <http://example.org/scripts/foo.xslt> ; > :transformer-kind :entire ; > :arguments [ > :argument [ > :name "debug" ; > :value false > ] ; > :argument [ > :name "other" ; > :value 123 > ] > ] ; > #:initial-context-node ... ; # See XSLT 2.0 spec. > initial-template "first" ; > initial-mode: "first" ; > completeness 0.9 ; > stability 0.9 ; > preference 0.9 > ] . > > 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. > > 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 [ > a :transformer ; > dc:description <http://...> ; > # Other Dublin Core metadata. > :source-namespace <...> ; > :target-namespace <...> ; > :precedence <...> ; > :script-data [ > a :xslt ; > :version "2.0" ; > :script-url <http://example.org/scripts/foo.xslt> ; > :transformer-kind :entire ; > :arguments [ > :argument [ > :name "debug" ; > :value false > ] ; > :argument [ > :name "other" ; > :value 123 > ] > ] ; > #:initial-context-node ... ; # See XSLT 2.0 spec. > initial-template "first" ; > initial-mode: "first" ; > completeness 0.9 ; > stability 0.9 ; > preference 0.9 > ] > ]. > > 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?) > > 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? > > 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 -- Victor Porton - http://portonvictor.org
Received on Wednesday, 9 July 2014 19:36:14 UTC