Hi Michel,
First, a bit of clarity seems to be required wrt understanding some basics of RDF/OWL. RDF/XML, Turtle, etc are encoding graphs, which by-definition have no order or hierarchy. There is no top, bottom or middle of a graph. Therefore, ordering is not important in any Turtle and RDF/XML encoding. Contrast that with XML which is encodes a strictly ordered set of XML elements and hierarchy/containment relationships plus attributes on the XML elements. Graphs and XML are nothing alike and mixing requirements between them is not a sensible thing to do. >The situation is IMHO subtly different: * Any RDF Document (in whatever encoding aka concrete RDF syntax) DOES have an order. Of course this order does have no semantic meaning (or as you say ‘the encoded graph does have no order’). Likewise all concrete RDF syntaxes have a concept of ‘Comment’. Again no semantic machine-interpreted meaning. Because of this ordering, also comments make sense (since a comment is typically location-sensitive having 1) no order and 2) comments would not really make sense at document level. * The next but separate question is: when imported/exported into a tool (say tbc), should the comments/order be preserved somehow or not? When the data is read into a platform once, becomes the primary source and in the end is only processed via SPARQL you do not care. The originating Turtle doc can be deleted or just left there for human information only. * Since many rdf data (lets focus here on ontologies) is in practice still imported , edited and exported by tools as files/documents in concrete RDF syntaxes (and not only via direct sparql/SOH access etc.) I would say the processing of order/comments IS an issue It does not make sense to decide whether to use IFC EXPRESS and STEP file format vs IFC OWL and Turtle for data exchange based on a manually controlled Turtle file format. If that is important in your argument, IMO you’ve got entirely the wrong argument :-) * Sorry David, you completely missed my point. Let’s formulate it differently: I have seen end-users reading in Turtle (ontologies), editing with tbc and then say “hey tbc deleted all my comments!” It did not even warn me for that when I saved. * Anyway, the issue is only there when editing. If files are read-only there is of course no issue. Also when RDF documents are not used as primary source but the RDF Documents are only there for data exchange again there is no issue, * To be clear the whole issue is for me only relevant for ontologies not data files (don’t care much about order and comments in data files). If you have further concerns, I suggest you take them up with me directly rather than on the user forum since I understand the IFC STEP issues and most Composer developers and users don’t. I’m happy to help make the argument to IFC STEP users. How about : For real-world uses of RDF/OWL, it is very likely that the data will end up in an RDF database anyway, and so the fact that it was ever encoded as Turtle disappears entirely. >Finally, Here we totally agree!, if Turtle (or any concrete RDF syntax) >becomes completely irrelevant in future because all instantiation and changing >is done via direct interface like SPARQL, all issues that arose by combining >RDF Documents and RDF Datasets also become fully irrelevant! So let’s work >hard to make Turtle a formal W3C Condemnation (is that the opposite of a >Recommendation?). >Gr Michel Cheers, David UK +44 7788 561308 US +1 336 283 0606 On 13 Jul 2017, at 09:13, Bohms, H.M. (Michel) <[email protected]<mailto:[email protected]>> wrote: Hi Holger, see after >: On 12/07/2017 21:11, Bohms, H.M. (Michel) wrote: Sorry bit late reply… When I save, all comments (edited/added manualy) are gone and order is changed. (can’t remember I changed a setting for that behaviour, so guess default) After save (in ttl), order seems: * Comments baseURI/prefix/baseuri * Prefixes * Changed external entities * Ontology declaration * Classes (alphabet.) * Properties (datatype/object mixed) (alphabet.) Is there a way to overrule this and stick to manually determined order and keeping own comments? Yes, the only way to keep these is to not use TBC at all. * Maybe 😊, but I’ll try first the next scenario: * When ontology is fully stable add comments in file * From that point only read the file and never write/save again avoiding losing my order and comments * 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”). What you are asking for (and in the parallel thread) is almost impossible to implement for us. You are asking for a system that not only parses Turtle but also preserves the details of the formatting (e.g. commas vs semicolon) and # comments (which the parsers usually throw away). * That parallel issue is a completely different one not in the same league as the above. A writer that only supports 2 out of 3 (turtle) key language features is simply not fully complete even if the resulting turtle is fully valid turtle. If I would follow your reasoning you could actually write turtle without semicolons, commas and []. This would result in valid turtle but the end result is simply triples and that is not what you would expect from a Turtle writer since Turtle was just meant to add all this syntactic sugar to triples. * You say “e.g. commas vs semicolon”. This is not the case! Its about commas AND semicolons. These are fully orthogonal language features! So the issue is not about unimportant syntax-alternatives for the same concept, it’s about 2 different concepts (2 different ways to abbreviate your directed graph) where one is supported and not the other. 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). Greetings Michel Holger Gr 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=%213m1%214b1%214m5%213m4%211s0x47c5b58c52869997:0x56681566be3b8c88%218m2%213d52.000788%214d4.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]> [mailto:[email protected]] On Behalf Of Holger Knublauch Sent: vrijdag 23 juni 2017 00:48 To: [email protected]<mailto:[email protected]> Subject: Re: [topbraid-users] tbc ttl file questions On 22/06/2017 16:19, Bohms, H.M. (Michel) wrote: Dear, 2 simple/short technical questions: * Can the generated comments at the start of a turtle file be avoided somehow? When you just use the Save feature to produce a TTL file then the # baseURI lines will always be there. If you want to avoid them, you'd need to give up on the order of items in the file, which is currently preserved by default. * * Can the order of the items in the file be preserved? (related to # comments)? What problem are you trying to solve? Holger * Thx 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=%213m1%214b1%214m5%213m4%211s0x47c5b58c52869997:0x56681566be3b8c88%218m2%213d52.000788%214d4.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. -- 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]<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.
