User Tools

Site Tools


use_cases

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
use_cases [2011/06/22 13:59] – [Pubby Example] danieluse_cases [2011/06/22 14:04] (current) – [Pubby Example] daniel
Line 128: Line 128:
   * Rationale: The original provenance statements of the guide have been grouped in the DescriptionSet1 (date, creator and generation), according to our domain model. As shown in the previous snapshot, the description set is "described" by the "creator", "rights" and "date" properties, while the "performedBy" property, besides being at the same level as the prevoius three, refers to the creation of the whole RDF serialization showed to the user (i.e. the creation of the Anon_0 graph). Therefore the "creator", "rights" and "date" properties are grouped in the annotationSet1 and the "performedBy" property in the annotationSet2. The rest of the unfoldable fields in the graph have been modelled as description sets themselves, since they don't further describe the previous annotation sets. They are just subgraphs with common elements (like DataCreation1, DataCretionService1, etc.)   * Rationale: The original provenance statements of the guide have been grouped in the DescriptionSet1 (date, creator and generation), according to our domain model. As shown in the previous snapshot, the description set is "described" by the "creator", "rights" and "date" properties, while the "performedBy" property, besides being at the same level as the prevoius three, refers to the creation of the whole RDF serialization showed to the user (i.e. the creation of the Anon_0 graph). Therefore the "creator", "rights" and "date" properties are grouped in the annotationSet1 and the "performedBy" property in the annotationSet2. The rest of the unfoldable fields in the graph have been modelled as description sets themselves, since they don't further describe the previous annotation sets. They are just subgraphs with common elements (like DataCreation1, DataCretionService1, etc.)
   * RDF:   * RDF:
-Concern: the graph URI is made from the resource's URI, not via a direct assertion +The modelling using TriG Syntax and following the discussion of the last teleconf:
-Concern2the necessity of an additional graph per resource -> scalability problems?+
  
  
Line 167: Line 166:
  }  }
  
-Once the problem is solved, another interesting question would be how to access the metadata provenance of a resource, given its URI. Should I see the graph relationship when accessing example:guideIdentifier?+  * Concerns: 
 +   - The graph URI is made from the resource's URI, not via a direct assertion 
 +   - The necessity of an additional graph per resource -> scalability problems? 
 + 
 +Once the problem is solved, another interesting question would be how to access the metadata provenance of a resource, given its URI. Should I see the graph relationship when accessing example:guideIdentifier? How do I know that a resource has provenance without asking for it explicitly?. (How do I know that a triple belongs to a graph?)
  
 ===== OPMV ===== ===== OPMV =====
use_cases.1308751180.txt.gz · Last modified: 2011/06/22 13:59 by daniel

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki