Updated example in SIOC specification
Here is an updated example for the SIOC specification:
http://sparql.captsolo.net/spec/#sec-example
It is a draft version and will be included in the specification.
Waiting for your feedback.
Best regards,
Uldis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
- Login to post comments
This resource is supported by Science Foundation Ireland under grant number SFI/02/CE1/I131 (Líon) and SFI/08/CE/I1380 (Líon 2) at the Digital Enterprise Research Institute, National University of Ireland, Galway.
Syndicate
Updated example in SIOC specification
Hi,
On 9/27/06, Uldis Bojars wrote:
>
> Here is an updated example for the SIOC specification:
>
> http://sparql.captsolo.net/spec/#sec-example
>
> It is a draft version and will be included in the specification.
> Waiting for your feedback.
What about also using foaf:maker in this example ?
As it's what we decided to implement in exporters and API, could be
nice to get it in the spec example, even if indeed we could argue
foaf:maker could be inferred from sioc:has_creator.
Alex
> Best regards,
> Uldis
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Alexandre Passant wrote: wrote:
>
> On 9/27/06, Uldis Bojars
> >
> > Here is an updated example for the SIOC specification:
> >
> > http://sparql.captsolo.net/spec/#sec-example
> >
> > It is a draft version and will be included in the specification.
> > Waiting for your feedback.
>
> What about also using foaf:maker in this example ?
> As it's what we decided to implement in exporters and API, could be
> nice to get it in the spec example, even if indeed we could argue
> foaf:maker could be inferred from sioc:has_creator.
True, foaf:maker needs to be mentioned.
I did leave it out in order to make the example simple enough.
Having both in the example would make it more complex and lead to
longer explanations why there are 2 methods to indicate a creator, etc.
What we can do is include a paragraph about foaf:maker describing that
it can be used, similar to how AtomOWL and RSS 1.0 content module are
mentioned now.
For a more detailed description the specification can point to the
appropriate document - a SIOC User's Guide or the Related Vocabularies
document.
Best,
Uldis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Hi,
> Having both in the example would make it more complex and lead to
> longer explanations why there are 2 methods to indicate a creator, etc.
I agree.
> What we can do is include a paragraph about foaf:maker describing that
> it can be used, similar to how AtomOWL and RSS 1.0 content module are
> mentioned now.
> For a more detailed description the specification can point to the
> appropriate document - a SIOC User's Guide or the Related Vocabularies
> document.
I would suggest to refer to a "Best Implementation Practices" page. It has more
meaning for me than "SIOC User's Guide" or "Related Vocaularies" documents. In
fact, if I put myself in the skin of a guy that have no real knowledge in
ontologies and how it works, it gives me not a hint about what these documents
will help me to accomplish. The challenge for the SIOC ontology is making it
adopting by all web developers. The prime goal is to explain it in the easiest
way to make sure that any web developers will understand what is its benefit
for them.
My 2 pennies,
Salutations,
Fred
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
See http://sparql.captsolo.net/spec/#sec-example for an updated text.
It mentions FOAF and at the end of example section there is a link to a
real blog post's SIOC profile (that uses foaf:maker).
Will that be OK?
Uldis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Alexandre Passant wrote: wrote:
> Hi,
>
> On 9/27/06, Uldis Bojars
>
>>Here is an updated example for the SIOC specification:
>>
>>http://sparql.captsolo.net/spec/#sec-example
>>
>>It is a draft version and will be included in the specification.
>>Waiting for your feedback.
>
>
> What about also using foaf:maker in this example ?
> As it's what we decided to implement in exporters and API, could be
> nice to get it in the spec example, even if indeed we could argue
> foaf:maker could be inferred from sioc:has_creator.
>
> Alex
In fact, this is an interesting side issue: Although, the foaf :maker
could be inferred, this inferences might only be a default value, since
even if a foaf:Person is given with the respective sioc:User as value of
the foaf:holdsAccount property, the account may still be
a) actually shared by several persons
b) a different person might have used the account of someone else (with
permission).
i.e. the holdsAccount property is by no means inverseFunctional
necessarily...
This, in fact is an additional argument for keeping the foaf:maker and
sioc:user separate and yes it would be nice to have this reflected in
the example.
axel
Side remark: For similar reasons, the common (? from personal discussion
with Andreas Harth) practice to infer uniqueness of a foaf:person by
having the same foaf:mbox is not necessatily correct, although valid in
"most" cases.
--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Axel Polleres wrote:
> Alexandre Passant wrote:
> In fact, this is an interesting side issue: Although, the foaf :maker
> could be inferred, this inferences might only be a default value, since
> even if a foaf:Person is given with the respective sioc:User as value of
> the foaf:holdsAccount property, the account may still be
> a) actually shared by several persons
> b) a different person might have used the account of someone else (with
> permission).
You are "touching" a distinction between the real world and how it is
seen by a community site (e.g., weblog). All the site can know (or
assume) is that the account is used by the same person who has
registered it.
Analogy: bank assumes you are the one who is using a credit card issued
in your name and will not be aware if you give your card and its PIN
code to someone else.
You raise an interesting question - how to describe (in RDF) a
situation when someone is somebody else's account. An interesting
question, but probably there is only a small amount of real-world cases
that it applies to.
> This, in fact is an additional argument for keeping the foaf:maker and
> sioc:user separate and yes it would be nice to have this reflected in
> the example.
Agree about need for foaf:maker.
Do you want to have it in the example then?
How can we keep the example simple and still tell about foaf:maker?
Maybe add a foaf:maker "snippet" after the main example as a
demonstration how FOAF can be mixed with SIOC?
> Side remark: For similar reasons, the common (? from personal discussion
> with Andreas Harth) practice to infer uniqueness of a foaf:person by
> having the same foaf:mbox is not necessatily correct, although valid in
> "most" cases.
I recall Andreas Harth mentioning that inverse functional properties
like foaf:mbox are not the best choice for identifying resources, but
do now know the details. What does he propose to use instead?
You mention foaf:mbox as not always being a unique way to identify a
person. FOAF Vocabulary solves this by convention - the way how
foaf:mbox is defined:
"personal mailbox - A personal mailbox, ie. an Internet mailbox
associated with exactly one owner, the first owner of this mailbox.
This is a 'static inverse functional property', in that there is
(across time and change) at most one individual that ever has any
particular value for foaf:mbox."
If an email address is shared among a number of persons, then by
definition it is not a personal mailbox and according to the FOAF
specification is not a valid use of a foaf:mbox.
Uldis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Update: SIOC Specification
Hi All,
Updated the SIOC specification [1] with the latest changes.
[1] http://rdfs.org/sioc/spec/
What's remaining is to remove some "working" comments, to shorten the
text explaining what RDF is (we've now got the FAQ for that) and to
add a more detailed description of the Types module.
Please let me know if there are any other important changes needed.
Does anyone know a stable namespace URI for AtomOWL?
Thanks,
Uldis
[ http://sioc-project.org ]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: SIOC Specification
Hi,
I just noticed that, re. subclasses of sioc:Post, there is no WikiPage / WikiArticle type.
There's a wikiont#Article, but that's commented. Can it be re-introduced, or mapped with a sioc:WikiArticle type ?
Would be useful if we want to export wikis to SIOC
(actually I'm already using this in a project, but don't remember if it was there before or if I introduced it in a personal extension)
I think that's worth adding this before W3C submission.
Best,
Alex.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: SIOC Specification
Added a figure showing main classes and properties to:
http://rdfs.org/sioc/spec/#sec-overview
Some text changes may (or may not) be needed as a result.
Not sure if we need a Role in this figure. Historically it has always
been there, but it does not currently play so big a role (maybe in the
future). On the other hand, are there other important classes that
need to be mentioned?
Thread is a fine addition to SIOC, but with regard to this figure 3
main classes for content ( Site -> Forum -> Post ) are already enough,
adding more will only cause confusion.
Uldis
[ http://sioc-project.org/ ]
On 5/14/07, Uldis Bojars wrote:
> Hi All,
>
> Updated the SIOC specification [1] with the latest changes.
>
> [1] http://rdfs.org/sioc/spec/
>
> What's remaining is to remove some "working" comments, to shorten the
> text explaining what RDF is (we've now got the FAQ for that) and to
> add a more detailed description of the Types module.
>
> Please let me know if there are any other important changes needed.
>
> Does anyone know a stable namespace URI for AtomOWL?
>
> Thanks,
> Uldis
>
> [ http://sioc-project.org ]
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Uldis Bojars wrote:
>
> Axel Polleres wrote:
>
>>Alexandre Passant wrote:
>>In fact, this is an interesting side issue: Although, the foaf :maker
>>could be inferred, this inferences might only be a default value, since
>>even if a foaf:Person is given with the respective sioc:User as value of
>>the foaf:holdsAccount property, the account may still be
>
>>a) actually shared by several persons
>>b) a different person might have used the account of someone else (with
>>permission).
>
> You are "touching" a distinction between the real world and how it is
> seen by a community site (e.g., weblog). All the site can know (or
> assume) is that the account is used by the same person who has
> registered it.
>
> Analogy: bank assumes you are the one who is using a credit card issued
> in your name and will not be aware if you give your card and its PIN
> code to someone else.
(slight difference here: a credit card is indeed linked to one and only
one person, whereas there are no such constraints between foaf:Person
and foaf:onlineAccount.)
> You raise an interesting question - how to describe (in RDF) a
> situation when someone is somebody else's account. An interesting
> question, but probably there is only a small amount of real-world cases
> that it applies to.
>
>>This, in fact is an additional argument for keeping the foaf:maker and
>>sioc:user separate and yes it would be nice to have this reflected in
>>the example.
>
> Agree about need for foaf:maker.
> Do you want to have it in the example then?
>
> How can we keep the example simple and still tell about foaf:maker?
You could just add foaf:maker with Johns foaf-id as value...
moment, just checked Johns foaf file at
http://www.johnbreslin.com/foaf/foaf.rdf
he didn't give himself an id, well even better, than you can link
him with a blank node:
[...]
John Breslin
[...]
> Maybe add a foaf:maker "snippet" after the main example as a
> demonstration how FOAF can be mixed with SIOC?
>
>
>>Side remark: For similar reasons, the common (? from personal discussion
>>with Andreas Harth) practice to infer uniqueness of a foaf:person by
>>having the same foaf:mbox is not necessatily correct, although valid in
>>"most" cases.
>
> I recall Andreas Harth mentioning that inverse functional properties
> like foaf:mbox are not the best choice for identifying resources, but
> do now know the details. What does he propose to use instead?
>
> You mention foaf:mbox as not always being a unique way to identify a
> person. FOAF Vocabulary solves this by convention - the way how
> foaf:mbox is defined:
>
> "personal mailbox - A personal mailbox, ie. an Internet mailbox
> associated with exactly one owner, the first owner of this mailbox.
> This is a 'static inverse functional property', in that there is
> (across time and change) at most one individual that ever has any
> particular value for foaf:mbox."
You are right, I forgot to re-check this in the foaf spec, sorry for
being imprecise here... actually, I wonder why it has been defined like
that in foaf...
The problem is that mailboxes in general ARE NOT inverse functional!
email-addresses can (and are) also be shared by persons. So maybe at
least an additional distinction between
mbox and a subproperty personalmbox
(or, in order to stay backwards compatible)
mbox and a superproperty emailaddress
would be useful to be added in foaf as well, actually, I find it kind of
an idealized assumption that an email address belngs to exactly one person.
There would be the possibility to state similar conventions in sioc of
course, but I find the genericity of sioc:user a feature not a bug in
this sense.
axel
> If an email address is shared among a number of persons, then by
> definition it is not a personal mailbox and according to the FOAF
> specification is not a valid use of a foaf:mbox.
>
> Uldis
>
>
> >
>
--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Hi
On 9/27/06, Axel Polleres wrote:
>
> >
> > I recall Andreas Harth mentioning that inverse functional properties
> > like foaf:mbox are not the best choice for identifying resources, but
> > do now know the details. What does he propose to use instead?
> >
> > You mention foaf:mbox as not always being a unique way to identify a
> > person. FOAF Vocabulary solves this by convention - the way how
> > foaf:mbox is defined:
> >
> > "personal mailbox - A personal mailbox, ie. an Internet mailbox
> > associated with exactly one owner, the first owner of this mailbox.
> > This is a 'static inverse functional property', in that there is
> > (across time and change) at most one individual that ever has any
> > particular value for foaf:mbox."
>
> You are right, I forgot to re-check this in the foaf spec, sorry for
> being imprecise here... actually, I wonder why it has been defined like
> that in foaf...
> The problem is that mailboxes in general ARE NOT inverse functional!
> email-addresses can (and are) also be shared by persons. So maybe at
> least an additional distinction between
>
>
> mbox and a subproperty personalmbox
>
> (or, in order to stay backwards compatible)
>
> mbox and a superproperty emailaddress
>
> would be useful to be added in foaf as well, actually, I find it kind of
> an idealized assumption that an email address belngs to exactly one person.
Well, indeed, it might be not inverse functionnal between a e-mail and
a user, as a mail can be used by different people as you said, yet, I
think it is between an e-mail and a set of users (from 1 to many),
that's why foaf:mbox domain is foaf:Agent, not foaf:Person.
So if many people use a common e-mail, they should be in a foaf:Group.
Then the e-mail is associated with a group, where users can be added /
removed, keeping the inverse funcionnal property between the mail and
this group.
This is how I understand it in the specs, regarding what you just mentionned.
Best,
Alex.
> There would be the possibility to state similar conventions in sioc of
> course, but I find the genericity of sioc:user a feature not a bug in
> this sense.
>
> axel
>
>
> > If an email address is shared among a number of persons, then by
> > definition it is not a personal mailbox and according to the FOAF
> > specification is not a valid use of a foaf:mbox.
> >
> > Uldis
> >
> >
> > >
> >
>
>
> --
> Dr. Axel Polleres
> email: axel@polleres.net url: http://www.polleres.net/
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
Updated example in SIOC specification
Alexandre Passant wrote: wrote:
> Hi
>
> On 9/27/06, Axel Polleres
>
>>>I recall Andreas Harth mentioning that inverse functional properties
>>>like foaf:mbox are not the best choice for identifying resources, but
>>>do now know the details. What does he propose to use instead?
>>
>> >
>>
>>>You mention foaf:mbox as not always being a unique way to identify a
>>>person. FOAF Vocabulary solves this by convention - the way how
>>>foaf:mbox is defined:
>>>
>>>"personal mailbox - A personal mailbox, ie. an Internet mailbox
>>>associated with exactly one owner, the first owner of this mailbox.
>>>This is a 'static inverse functional property', in that there is
>>>(across time and change) at most one individual that ever has any
>>>particular value for foaf:mbox."
>>
>>You are right, I forgot to re-check this in the foaf spec, sorry for
>>being imprecise here... actually, I wonder why it has been defined like
>>that in foaf...
>> The problem is that mailboxes in general ARE NOT inverse functional!
>>email-addresses can (and are) also be shared by persons. So maybe at
>>least an additional distinction between
>>
>>
>>mbox and a subproperty personalmbox
>>
>>(or, in order to stay backwards compatible)
>>
>>mbox and a superproperty emailaddress
>>
>>would be useful to be added in foaf as well, actually, I find it kind of
>>an idealized assumption that an email address belngs to exactly one person.
>
>
> Well, indeed, it might be not inverse functionnal between a e-mail and
> a user, as a mail can be used by different people as you said, yet, I
> think it is between an e-mail and a set of users (from 1 to many),
> that's why foaf:mbox domain is foaf:Agent, not foaf:Person.
> So if many people use a common e-mail, they should be in a foaf:Group.
> Then the e-mail is associated with a group, where users can be added /
> removed, keeping the inverse funcionnal property between the mail and
> this group.
>
> This is how I understand it in the specs, regarding what you just mentionned.
Well, yes, you might be right, that the spec defines it like this, then
I could assign a shared email address to a person only via a blank node
of tyoe foaf:Group and linking the person to that group via
ex:person1 a foaf:Person; .
ex:hasEmail
=
_:B1 a foaf:Group;.
foaf:member person1;
foaf:mbox
well, a bit crooked, but ok.
axel
--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---