Dear Michel, I do not have an assumption that RDF data is always in some database, but I do assume that the files get ingested for processing into some tool/system that is capable of deserializing them. With this, I do not really understand the issue with respect to commas and ordering.
I do understand the issue with losing comments recorded using ##. As a solution, I recommend capturing them directly in RDF. Or using some other, more specific, properties such as prov:wasDerivedFrom or rdfs:seeAlso. Irene > On Jul 13, 2017, at 4:35 PM, Bohms, H.M. (Michel) <[email protected]> wrote: > > Dear Irene > > Under the assumption: > “rdf data is always in an RDF database (accessible by SPARQL) and RDF > Documents are ONLY for semantic exchange between such systems” > I fully agree 100 % with all your statements (and those of your colleagues). > > So the issue is about the “assumption”. > > I observe many situations where the primary/reference data (typically an > ontology) is in an RDF Document. You might say “this not good” or “this won’t > be in future” etc. but that is just a situation I observe a lot (and the > actual RDF1.1 specifications are certainly not clear that this shouldn’t be > the case either). > > An example (other than my own cmo.ttl): https://www.w3.org/ns/prov.ttl > <https://www.w3.org/ns/prov.ttl> > > This is a reference specification published on the web as RDF document (in > various dereferenceable serialisations). It can be imported in any RDF DB you > like but the reference spec IS an RDF Document (so this is another status > then “just for exchange”). > > In this ontology you find many comments like: > > “## Definitions from other ontologies” > > Or > > > “# The following was imported from http://www.w3.org/ns/prov-dc# > <http://www.w3.org/ns/prov-dc#>” > > > Now image you are the owner of such a reference ontology as RDF Document. > You should be aware that when editing your ontology, most tools (other than > text editors) will delete both order and comments (in general: all > non-semantic aspects of that document). > When I say “delete” I of course mean the sequence (not-parse/record+write) > which effectively deletes the comments and specific order after editing. > > The current formal specifications do not tell us much about the rightness of > assumptions above. Turtle specifies a comment mechanism but does not say ie > “be careful, comments are only relevant when writing files, after parsing all > will be lost” or something similar. > > I also agree (with Holger) that if that second interpretation (RDF doc as > primary/reference) is assumed it is quite a job to record the non-semantic > info and reuse that when writing out again. (in the ISO STEP world the same > issue is relevant and some tools actually retain the non-semantic data in > STEP Physical Files to support more deterministic documents. In some > situations this simplifies model comparisons; I am not saying this is the > right approach, only saying it happens). > > I hope I made the issue at least more clear now. > > Greetings, Michel > > > > Dr. ir. H.M. (Michel) Böhms > Senior Data Scientist > > T +31888663107 > M +31630381220 > E [email protected] <mailto:[email protected]> > Location > <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707> > > > <image001.gif> <http://www.tno.nl/> > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use it > and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. > > > > > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Irene Polikoff > Sent: donderdag 13 juli 2017 20:32 > To: [email protected] <mailto:[email protected]> > Subject: Re: [topbraid-users] tbc ttl file questions > > Michel, > > Serializations and deserialization provide a way for data to be translated > into a format that could be used for transmission, interchange, storage in a > file system, etc. with the ability for it to be later reconstructed to create > semantically identical clone of the data. > > The goal of RDF serializations and tool interoperability is to ensure that if > tool A produces a serialization of a graph X, tool B can read it in and > understand it as graph X. Tool B can then, in its turn, produce serialization > of graph X, tool A can import it and it is still the same graph. The > serialization output of A may not look exactly the same as the serialization > output of B, but their semantic interpretation is always the same. > > Serialization/deserialization process is not intended to ensure that the > sequence of bytes in a file will be exactly the same. In case of both > RDF/XML and Turtle format, there are several syntactic variations for > representing the same information. The simplest RDF serialization is > N-Triple. There is little room in it for syntactic variations as it just > contains triple statements. However, even with that simplicity, there are > variants since the order of statements may vary. The bottom line is that if > you are using serializations in the interchange and parse them to deserialize > for use in some target system, you need a parser that will understand what > the serialization means semantically and will not rely purely on the byte > sequence. > > If TBC parser was ignoring something that captured semantics of data, this > would be a bug. I do not think it is the case. Comma is not ignored, it is > correctly understood by deserialization when data is imported into TBC. > “Deleting it” is not even a concept because once data is deserialized, comma > no longer exists. We now have a graph. When you save it, it is serialized > anew - without any memory or consideration of how its serialization looked > when it came in. As long as the serialization still represents semantically > identical object, it is correct. > > Regards, > > Irene Polikoff > > > On Jul 13, 2017, at 4:13 AM, Bohms, H.M. (Michel) <[email protected] > <mailto:[email protected]>> wrote: > > Seriously, if these low-level details of the TTL syntax are relevant to you, > just use text editors. > > Yes, low-level syntax issues ARE very relevant. They are the fundament under > all we do in the end. When convincing our client to move from SPFF or XML to > RDF and its serializations they expect implementations that 100% support > these specs. If a comment is a feature of that spec, if a comma is a feature > of that spec they do not expect that a parser and or writer ignores or even > deletes them. Anyway as said before, lets agree to disagree (although your > views in these matters highly surprise me I must say). > > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
