in fact teamwork:UserDefinedProjectType is an instance of teamwork:ProjectType
- so how does "subclass" work in this case? (and these dont seem to show up searching for resource with Ctrl-Shift-R - yet it shows up an an instance from the imported teamwork ui stuff.. ) On Tuesday, 17 July 2018 19:40:05 UTC+10, Rob Atkinson wrote: > > > spiralling back into chaos here: > > i now get properties label vocabulary and vocabularyType. > > I have a project that shows up OK in EDG. > > If I try to add that as the projectType us add existing it doesnt show up > as an option... but what show up is > > teamwork:UserDefinedProjectType with the message > > Customers who wish to define their own vocabulary types should subclass > teamwork:UserDefinedProjectType > > but of course, having followed instructions - my EDG projectType is an > instance > > and in that file the class teamwork:UserDefinedProjectType is not visible > - so its not imported. > > so how to interpret this? > > (IMHO every single instruction in TBC needs to have a context that clearly > lists the assumed imports - and maybe dynamic document building could check > when some sub-instruction needs different imports from where it is being > referenced as a context... ) > > > > > > On Tuesday, 17 July 2018 18:34:17 UTC+10, Holger Knublauch wrote: >> >> >> >> On 17/07/2018 17:49, Rob Atkinson wrote: >> >> what does "The script's function must use either >> teamworkscripts:suitableProjectType or teamworkscripts:suitableVocabulary >> to declare the scope of asset collections that it can be applied to." mean >> >> does that mean i need to access the function as en entity in the form and >> set its supertype? Or are these properties (do not show up in properties >> view) >> >> so where is teamworkscripts.ttl ? Do i need to find it and import it for >> this to work? It doesnt appear to exist in TBC (5.5) >> >> >> If you don't know where a file is, try Open Resource (Ctrl-Shift-R). >> >> This one is at teamwork.topbraidlive.org\system\teamworkscripts.ttl >> >> and the properties should be self-explanatory when you navigate into them. >> >> Holger >> >> >> >> >> On Tuesday, 17 July 2018 17:15:26 UTC+10, Holger Knublauch wrote: >>> >>> >>> >>> On 17/07/2018 17:00, Rob Atkinson wrote: >>> >>> >>> OK - I think i understand this. >>> >>> So a quick question - if I want to pre- test the SM function in TBC >>> using the rather nice visual debugger (and ability to document and explain >>> the workflow logic!) how best to wrap the script with a module to load the >>> input file and save the results? Is it possible to embed one SM script in >>> another? >>> >>> (or in this case refactor a visual script that imports files and saves >>> results and turn it into a function without losing the ability to test it >>> this convenient way? ) >>> >>> >>> Just select the ReturnRDF module and press the usual run button. You >>> will then be asked to paste the content of the file (upload) into a dialog. >>> Alternatively, the function is also a SPARQL function that can be called as >>> such. >>> >>> >>> Another question relating to generating visual overview documentation - >>> there is a implicit and interesting graph of how a set of EDG components >>> fit together - if i graph this as instances its kind of nice - but is there >>> a way to persist this graph as an editable entity, in the same way >>> sparqlmotion persists its rendered workflow graph? >>> >>> >>> Not exactly sure what you mean (which instances are the "EDG >>> components"), but the Graph tab in TBC has a save snapshot button to save >>> the coordinates. >>> >>> Holger >>> >>> >>> >>> >>> >>> >>> On Tuesday, 17 July 2018 16:34:20 UTC+10, Holger Knublauch wrote: >>>> >>>> Hi Rob, >>>> >>>> I am updating the documentation of this feature and will include a text >>>> such as the following, on teamworkscripts.ttl >>>> >>>> -- >>>> A small vocabulary that can be used to annotate SPARQLMotion scripts so >>>> that they can be used in the "Import File using Script" feature with >>>> selected asset collections. The user interface of such script-based >>>> importers asks for a file to be uploaded and then uses a script created by >>>> a SPARQLMotion expert to produce RDF triples as output. These RDF triples >>>> then are added to the currently open production copy or working copy. The >>>> uploaded file may be of any text-based format including comma-separated >>>> values, JSON or XML. >>>> >>>> To get started, create a SPARQLMotion file (with .sms.ttl ending) and >>>> import this teamworkscripts.ttl namespace into it. The file must define >>>> one >>>> sm:Function that takes exactly one argument of type string. The name of >>>> this argument is arbitrary. When called, the argument will have the text >>>> content of the uploaded file as its value. >>>> >>>> The script can access the current context graph (either the production >>>> or working copy) using sml:ImportCurrentRDF. >>>> >>>> The return module of the script must be of type sml:ReturnRDF. >>>> >>>> The script's function must use either >>>> teamworkscripts:suitableProjectType or teamworkscripts:suitableVocabulary >>>> to declare the scope of asset collections that it can be applied to. >>>> >>>> Once the script has been declared correctly, as above, and the .sms.* >>>> file is in the workspace of the EDG installation, users would see a fully >>>> clickable entry for the script on the Import tab. For custom >>>> teamwork:ProjectTypes, make sure that teamwork:ScriptBasedImportPlugin is >>>> declared as a teamwork:projectPlugin. >>>> >>>> -- >>>> >>>> Maybe this helps? >>>> >>>> I noticed that this feature is currently on visible for production >>>> copies (master graph) but I will enable it for working copies too. >>>> >>>> On 17/07/2018 10:08, Rob Atkinson wrote: >>>> >>>> The EDG developer guide states >>>> >>>> "There is also a generic SPARQLMotion-based importer mechanism that >>>> applies to all vocabulary types. Such importers receive an uploaded file >>>> as >>>> input and produce triples that shall be added to the current vocabulary or >>>> working copy. In order to create such importers, store them in a file >>>> ending with .sms.*. Import the file teamworkscripts.ttl and use the >>>> properties defined therein to link your sm:Function either with a >>>> vocabulary type or specific vocabularies for which the function shall show >>>> up. The script needs to end with sml:ReturnRDF and take exactly one >>>> string argument - the body of the uploaded file." >>>> >>>> there are no links and am not finding anything via google or help. >>>> >>>> - so i'm trying to interpret just what " to the current vocabulary or >>>> working copy" means - and what it means for design of custom importers. >>>> >>>> poking around in the code base I find reference to >>>> teamwork:scriptBasedFileImport >>>> >>>> and teamwork:ScriptBasedFileImportService >>>> >>>> with an arg:script: sm:Function parameter >>>> >>>> so presumably this means a sparqlmotion script that returns a RDF graph? >>>> >>>> There are a few moving parts in an EDG importer - >>>> the plugin >>>> which references a entry page >>>> which calls a service >>>> which calls a function inside a transaction context >>>> >>>> there seems to be a fair bit of contract implied in each of these >>>> layers - and teamwork logic is at the heart of it all. >>>> >>>> There are three separate graphs involved (?) - the data being >>>> imported, the project (data asset) and its "teamwork graph". How does >>>> the "working copy" concept and the importer relate? >>>> >>>> EDG default importers appear to put data into the production copy, but >>>> there are also transactions involved - so what state is the production >>>> copy >>>> in during the import process? >>>> >>>> >>>> The importer script only produces new triples. The surrounding engine >>>> then adds those triples as a transaction. The state of the current graph >>>> is >>>> whatever triples are in there before the import. >>>> >>>> Holger >>>> >>>> >>>> >>>> Maybe there is some resource that lays this out like a proper Use Case >>>> with specified pre-conditions and post-conditions. In a design-by-contract >>>> environment like TBC we need to know the contract :-( >>>> >>>> I suspect there is probably some resource out there that explains all >>>> this - but neither links or search are my friend.. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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 topbraid-user...@googlegroups.com. >>>> 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 topbraid-user...@googlegroups.com. >>> 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 topbraid-user...@googlegroups.com. >> 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 topbraid-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
