Right, and I am actually in favour of that. Fact is not all serialisations have that idea. Turtle and RDF/XML do have comments and people ARE using them in practice (cmo, prov ,…).
So let’s conclude: “Despite being offered the possibility better not use comments in your RDF Documents (or assume any order)”. In a sense these things are one order worse than annotations: where annotations are processed but not interpreted, comments and not even processed. So we agree on the “what should be”, but differ on the use in practice. That’s fine for me. Maybe you can consider in your system some warnings on save: “when saving not all features of your original input will be retained”. Thx for the discussion, 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> [cid:[email protected]]<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]] On Behalf Of Holger Knublauch Sent: vrijdag 14 juli 2017 00:05 To: [email protected] Subject: Re: [topbraid-users] tbc ttl file questions FWIW some formats such as JSON (and thus JSON-LD) don't even support comments. The philosophy behind that is that every piece of information should become data and not be hidden in a specific serialization. Holger On 14/07/2017 5:35, Irene Polikoff wrote: Yes, I agree with Tim. If comments are about an entire graph/ontology, then use rdfs:comment to record them and use as the subject of the comment statement an identifier/name of a model. If comments pertain to a subset of the resources described in a model, then Identify the subset and associate the comments with it. Irene Polikoff On Jul 13, 2017, at 2:48 PM, Tim Smith <[email protected]<mailto:[email protected]>> wrote: Ok, now we have the "reason" for needing this functionality: Michel wrote: " I explain why important: we have this concept modelling ontology (CMO) supporting different modelling styles (decomposition, qudt2.0 etc.). I would like to group the mechanisms for the different modelling styles together and introduce the groups with a comment. Alternative is to introduce an annotated clone of the file for information but I do not like that. Yet another alternative is to annotate all items separately (“supports modelling style x”)." It's interesting to me that you have used an ontology to capture the knowledge in your domain and then want to use a "document" (i.e. comments and proper ordering) to capture additional knowledge about the objects in your CMO. Could you not create another ontology with a classes like "Modeling Style Mechanism" and "Modeling Stype Group" and then create Modeling Style Group instances and link the various mechanism instances to it using an appropriate property? Then you have a fully query-able representation of your modeling mechanisms, making the information easily discoverable, displayable, etc... Ontologies are just triples and unless you care about strict inferencing, you can interchangeably use a Class as an instance or a Class. I use this all the time to capture knowledge and data using the same ontologies. Just a thought, Tim On Thu, Jul 13, 2017 at 2:31 PM, Irene Polikoff <[email protected]<mailto:[email protected]>> wrote: 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. -- 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. -- 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. -- 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. -- 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.
