What are profiles?

The thread on how to make containers is getting sidetracked into 
what Profiles are, which is an interesting topic. So I thought 
about it and tried to clarify it below.

The basic general idea is that one may want to specify certain types 
of documents as satisfying some restrictions, so that for example an 
LDPC could say that it only accepts POSTS of graphs of certain types:
perhaps something like a graph containing shopping artefacts. 

This idea would be to have something somewhat similar to 
  http://tools.ietf.org/html/draft-wilde-profile-link-04#section-3.1
but with a more semantic twist to it, and completely orthogonal
to syntactic issues as specified by a mime type. 

Any well formed document with a mime type should have semantics, 
and there may be different types of documents that have the 
same semantics ( say Atom/XML and  a future atom/json version ).

What is a Profile?
------------------

Having said that one could start very minimally by naming 
the class of Profiles

{
  @prefix webarch: <http://sw.nokia.com/WebArch-1/> .

  :Profile a rdf:Class;
      rdfs:comment "the class of things that are profiles" .

  :profile a rdf:Property;
     rdfs:comment "the relation of a particular information resource to the Profile it satisfies";
     rdfs:domain webarch:InformationResource ;
     rdfs:range :Profile .

}

One can think of many classes of Information Resources as being  related implicitly
to such a Profile. 

  { ?x a foaf:PersonalProfileDocument } => { ?x :profile ?y }

It is just that the profile of a foaf:PersonalProfile document has not been
stated yet. What could it be? My guess is that for a foaf:PersonalProfileDocument 
the restriction is something like the following

{
  @prefix log: <http://www.w3.org/2000/10/swap/log#>.

  # a foaf:PersonalProfileDocument states that it is a document and has a primary topic
 
  { 
    ?x a foaf:PersonalProfileDocument 
  } => { 
    ?x log:semantics [ log:includes { ?x a foaf:PersalProfileDocument;
                                         foaf:primaryTopic ?y . } ] .
  }
}

A foaf:PersonalProfileDocument must have a primaryTopic. This is just a rough
sketch of course.

Similarly one could say that an LDPC states  that it is an ldp:Container

{
  @prefix log: <http://www.w3.org/2000/10/swap/log#>.
  # see http://www.w3.org/2000/10/swap/doc/CwmBuiltins
  # and http://www.w3.org/2000/10/swap/doc/Reach
  
  { ?c a ldp:Container . } => { ?c log:semantics [ log:includes { ?c a ldp:Container } ] }
     
}

The inverse is not true. It is not because something states that it is an ldp:Container
that it is. The thing also needs to behave like one.  So this is false:

 { { ?c a ldp:Container . } <= { ?c log:semantics [ log:includes { ?c a ldp:Container } ] } } 

Perhaps this is where the notion of a profile comes in:

 { ldp:ContainerProfile rdfs:subClassOf :Profile }

 we can now go the other way, and say that something that says it is a container satisfies
the ContainerProfile

{ ?c log:profile ldp:ContainerProfile }  <= { ?c log:semantics [ log:includes { ?c a ldp:Container } ] } 

Now here we relate an information resource to a containerProfile. Perhaps
Container profiles are then graphs such that the following holds

 { ?g a ldp:ContainerProfile . } <=> { ?g log:includes { <> a ldp:Container . } }

I am hoping it says: a graph is a ldp:ContainerProfile, if the graph contains a statement about it being a ldp:Container.

( I say I am hoping, because I am not sure if N3 allows <> to refer to the graph inside of which it is placed - 
  perhaps an improvement for N3... ) 

In any case it seems quite clear that profiles are restrictions on graphs given
what statements they contain, without it making a claim on the truth value of the claim. 
This then explains why people wish to add profiles to mime types: if something is
not related to a truth evaluatable statement one may come to think that it is a syntactic
one. But that is to forget that different languages can express the same thing,
and so why profiles can be expressed semantically - in a somewhat modal manner I think.

This is why I mentioned SPARQL as the obvious way to proceed to defined profiles, 
in a way that is independent of any syntax. One could then defined profiles for 
ldp:Containers, and if one has a GRDDL of Atom, one could independently of 
the media type assert that an atom Container satisfies an ldp:ContainerProfile.



Henry

Social Web Architect
http://bblfish.net/