Differences

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

--- use_cases [2011/06/07 22:02] – [Pubby Example] daniel
+++ use_cases [2011/06/22 16:04] (current) – [Pubby Example] daniel
@@ Line 120: / Line 120: @@
 ===== Pubby Example =====
   * Description: Pubby is a Linked Data Frontend for SPARQL endpoints. It allows exploring and navigate through the links of the endpoint, solving the 303 redirection problems and dealing with the content negotiation. It also includes a metadata extension to add metadata to the provided data (provenance information). This metadata is described by default by the Provenance Vocabulary, but can be configured with the metadata.ttl file.
-  * Problem: If we are trying to publish metadata about provenance information, the current modeling can be quite confusing (is the publisher of the annonymous graph Anon0 the publisher of the resource or the publisher of the metadata aboout the resource?). The modeling of this example might
+  * Problem: If we are trying to publish metadata about provenance information, the current modeling can be quite confusing (is the publisher of the annonymous graph Anon_0 the publisher of the resource or the publisher of the metadata aboout the resource?). The modeling of this example with our domain model might be a good example to illustrate how to use it in a real use case, as well as an alternative for the current representation.
-  * Rationale:
+  * Use case: The published provenance information is about the travel guides, images and videos of "El Viajero" (a section of the spanish newspaper "[[http://elviajero.elpais.com/|El País]]"). There is also additional descriptive metadata about the guides, such as the longitude in words of the guide, the size of the picture, etc., but we will leave it out of the scope of the example modeling. The endpoint can be found [[http://webenemasuno.linkeddata.es/sparql|here]]. Below, it is described the model and the rationale for it, selecting only a few provenance statements about a travel guide identifier.
-  * Model:
+  * Original Pubby Modeling. The metadata section refers to the statements that appear in the pubby file. The metadata is divided in annonymous graphs, some of them with the type rdf:Graph and some not (being concepts of the Provenance Vocabulary, such as DataCreation). By clicking on the "More" links we can unfold the subgraphs contained in the Anon_0 graph, being able to explore their contents. A snapshot of the metadata section can be seec in the next figure.
+{{:pubby.png|}}
+  * Modeling with our domain model:
 {{:pubbyexample.png|}}
+  * 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:
+The modelling using TriG Syntax and following the discussion of the last teleconf:
+	@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
+	@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+	@prefix dc: <http://purl.org/dc/elements/1.1/> .
+	@prefix dcterms: <http://purl.org/dc/terms/>.
+	@prefix dcprov: <http://namespaceNotYetKnown/.
+	@prefix example: <http://example.org/data/> .
+	#default graph
+		{
+			#this naming would allow to automatically refer to the description set from the resource
+			<http://example.org/data/guideIdentifier/prov> a dcprov:DescriptionSet .
+			<http://example.org/data/AnnotationSet/annSet1> a dcprov:AnnotationSet .
+			<http://example.org/data/AnnotationSet/annSet2> a dcprov:AnnotationSet .
+			<http://example.org/data/AnnotationSet/annSet1> dcprov:describes <http://example.org/data/guideIdentifier/prov> .
+			<http://example.org/data/AnnotationSet/annSet2> dcprov:describes <http://example.org/data/AnnotationSet/annSet1> .
+		}
+	#DescriptionSet1
+	<http://example.org/data/guideIdentifier/prov>
+		{
+			example:guideIdentifier dc:date "2011-05-27"^^xsd:date.
+			example:guideIdentifier dc:creator example:Paco_Nadal.
+			example:WasGeneratedBy1123344 opmo:cause example:guideIdentifier .
+		}
+	#AnnotationSet1
+	<http://example.org/data/AnnotationSet/annSet1>
+		{
+			<http://example.org/data/guideIdentifier/prov> dc:creator "2011-05-28"^^xsd:date.
+			<http://example.org/data/guideIdentifier/prov> dc:date example:Prisa_Digital.
+			<http://example.org/data/guideIdentifier/prov> dc:publisher example:UPM.
+		}
+	#AnnotationSet2
+	<http://example.org/data/AnnotationSet/annSet2>
+		{
+			<http://example.org/data/AnnotationSet/annSet1> prv:dataCreation example:DataCreation1.
+		}
+  * 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 =====
 ** Use Case **