Changes between Initial Version and Version 1 of RdsWipUseCaseCSVUpload

Show
Ignore:
Timestamp:
06/23/08 05:34:01 (16 years ago)
Author:
jbourne (IP: 70.54.77.119)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RdsWipUseCaseCSVUpload

    v0 v1  
     1= RDS/WIP Use Case: CSV Upload = 
     2 
     3This page notes the case for upload of definitions specified in comma-separated variable (CSV) format to the [wiki:RdsWipProject RDS/WIP]. 
     4 
     5== Fundamental Drivers == 
     6 
     7The use case for CSV upload of definitions into the RDS/WIP stems largely from these fundamental drivers: 
     8 
     9 * the discomfort of engineers with technology such as OWL/RDF and its related tools 
     10 
     11 * the familiarity of engineers with tabular formats and tools such as spreadsheets 
     12 
     13 * the existing definition of dictionary style materials in this or a similar format 
     14 
     15 * the mandated use of such formats by other bodies such as SC4. 
     16 
     17== Use Case for RDS/WIP 1.0 == 
     18 
     19In the next [wiki:RdsWipOnePlan RDS/WIP release (1.0)], the easiest way to conceive of this working is that contributors pass SC4 specified definitions to DNV's IRM team, along with some guidance about the intended 
     20endpoint and function. 
     21 
     22At this point, the IRM team will need to make an internal decision about the material: if it is intended to 
     23be included in the RDS/WIP per se, then it might be best to enter it via the Brutus system, for eventual 
     24automatic upload into the RDS/WIP via the usual means specified for that process.  Since submission is via Brutus under existing contractual arrangements between DNV and POSC Caesar (I think - Julian), and the IDS-ADI RDS/WIP service itself is ultimately intended to be a free one for contributors, then so long as the input is SC4 compliant, it would be best if the submitter is not charged (this should be OK because it should all be an automatic process anyway). 
     25 
     26On the other hand, if it is intended to be its own endpoint (for example, its not intended to be ISO 15926 compliant), then it will need to be transformed into RDF in some way and then uploaded directly into the RDS/WIP.  How this is achieved, where the costs will be borne etc. are all internal matters for IRM, possibly up for negotiation with the submitter. 
     27 
     28Similarly, if the definitions are intended for ISO 15926, but are not in the SC4 form, then it would be reasonable for the work required to analyse and recast the data in compliant terms to be negotiated and charged for. 
     29 
     30== Use Case for RDS/WIP 2.0 == 
     31 
     32In the following [wiki:RdsWipTwoPlan RDS/WIP release (2.0)] the means will exist for users to directly interoperate with the RDS/WIP server to perform bulk uploads of OWL/RDF definitions.  The problem will be, what if they cannot or do not want to use OWL/RDF? 
     33 
     34So long as the SC4 format is sufficiently rich, it should be possible to create an SC4 CSV to OWL/RDF format converter that could be used as a standalone conversion tool.  This sort of tool will be useful for people wanting to learn about ISO 15926 representation in OWL/RDF. 
     35 
     36Longer term, it would be theoretically possible to integrate such functionality into the submittal framework - allowing submissions to be made in OWL/RDF or SC4 CSV. 
     37 
     38Ad-hoc CSV will never be supported directly, however, its possible that 3rd parties with the necessary skillsets (such as DNV's IRM section) could charge to transform CSV data into compliant SC4 CSV, raw RDF or ISO 15926 OWL/RDF formats. 
Home
About PCA
Reference Data Services
Projects
Workgroups