Flat syntax for structured model

Metadata on the server (in N3/RDF)

 <http://example.com/file1.jpg> a ont:ImageFile ;
   ont:widthInPixel "240"^^xsd:int ; 
   ont:heightInPixel "320"^^xsd:int ;
   ont:resolutionInDpi "75"^^xsd:int ;
   ont:dateCreated "2008-11-21" ;
   ont:instanceOf <http://example.com/photo1> .
 
 <http://example.com/photo1> a ont:AnalogPhoto ;
   ont:creator <http://champin.net/foaf.rdf#pa> ;
   ont:exposure "1/1000" ;
   ont:dateCreated "2008-11-19" ;
   ont:depicts <http://example.com/painting1> .

 <http://example.com/painting1> a ont:Painting ;
   ont:creator <http://painters.com/foaf.rdf#vincent> ;
   ont:title "Self-portait" ;
   ont:dateCreated "1887-04" .

 <http://champin.net/foaf.rdf#pa> a foaf:Person ;
   foaf:name "Pierre-Antoine Champin" .

 <http://painters.com/foaf.rdf#vincent> a foaf:Person ;
   foaf:name "Vincent van Gogh" .

Flat syntax (proposal 1)

Here, all relevant metadata, possibly inherited, is included with a plain property. The notion of relevance could probably be decided by the server itself.

The notion of inheritance, on the other hand, should probably be specified by the ontology. Especially, what should happen when different values are inherited (through different paths) for the same property (here: creator)? Should the "closest" one have precedence ? Should they be merged?

Furthermore, structured values are replaced by a textual label. The server, depending on the external ontologies it uses (here, the FOAF ontology), decides on the most appropriate property to be used as a label. For disambiguation purposes, however, the URI should be conveyed as well.

Example where the closest metadata overrides the further ones. Note that an additional metadata has been used, giving access to the complete structured version.

   type               "ImageFile"
   widthInPixel       "240"
   heightInPixel      "320"
   resolutionInDpi    "75"
   dateCreated        "2008-11-21"
   creator            "Pierre-Antoine Champin"
   creator_uri        "http://champin.net/foaf/rdf#pa"
   exposure           "1/1000"
   title              "Self-portait"
   structuredMetadata "http://example.com/file1.rdf"

Flat syntax (proposal 2)

In order to keep more of the underlying structure, property names could be complex, representing paths in the graph. This would give more information to the client about the underlying structure.

Note that we keep te

   type                "ImageFile"
   widthInPixel        "240"
   heightInPixel       "320"
   resolutionInDpi     "75"
   dateCreated         "2008-11-21"
   instanceOf/type        "AnalogPhoto"
   instanceOf/creator     "Pierre-Antoine Champin"
   instanceOf/creator_uri "http://champin.net/foaf.rdf#pa"
   instanceOf/exposure    "1/1000"
   instanceOf/dateCreated "2008-11-19"
   instanceOf/depicts/type        "Painting"
   instanceOf/depicts/title       "Self-portait"
   instanceOf/depicts/dateCreated "1887-04"
   instanceOf/depicts/creator     "Vincent van Gogh"
   instanceOf/depicts/creator_uri "http://painters.com/foaf.rdf#vincent"
   structuredMetadata "http://example.com/file1.rdf"

This has the advantage of conveying much more information to the client, for example the different creators and creation dates, together with their different meanings.

Accessing a metadata with the API would look cumbersome in that situation, but the API could provide the same inheritance mechanism as the server in the previous example. I.e.

 md = file1.getMetadata()
 title = md.getProperty("title") // return the "closest" title property
 proper_title = mg.getExactProperty("title") // return null, since there is no "direct" title

Flat syntax (proposal 3)

A problem with the previsous proposal is that the burden of implementing inheritance is left to the client side API, making it less likely to be adopted by browser developers.

An alternative would be to let the server compute the inheritance, but keep the information about how the value was obtained in the flat structure (with some meta-metadata about the value).

   type               "Painting"    (/instanceOf/depicts)
                      "AnalogPhoto" (/instanceOf)
                      "ImageFile"   (/)
   widthInPixel       "240" (/)
   heightInPixel      "320" (/)
   resolutionInDpi    "75" (/)
   dateCreated        "2008-11-21" (/)
                      "2008-11-19" (/instanceOf)
                      "1887-04"    (/instanceOf/depicts)
   creator            "Vincent van Gogh"       (/instanceOf/depicts)
                      "Pierre-Antoine Champin" (/instanceOf)
   creator_uri        "http://painters.com/foaf.rdf#vincent" (/instanceOf/depicts)
                      "http://champin.net/foaf.rdf#pa"       (/instanceOf)
   exposure           "1/1000" (/instanceOf)
   title              "Self-portait" (/instanceOf/depicts)
   structuredMetadata "http://example.com/file1.rdf"

This allows us to safely keep multiple values for the same property. The API would provide simple calls (returning only the first value, without the path) and more complex ones (iterating over all the value, giving the path for each one). Note that the ordering here would be significant. It means that the server can decide which value to promote as the default one. This policy is dependant on the server. E.g. a museum server would consider the most significant type to be "Painting", while a photo sharing would prefer "AnalogPhoto".